all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* Re: Preparing the reduced bootstrap tarballs
@ 2018-11-21  3:36 Jeremiah
  0 siblings, 0 replies; 23+ messages in thread
From: Jeremiah @ 2018-11-21  3:36 UTC (permalink / raw)
  To: rekado, samplet; +Cc: guix-devel

> Now that’s a project for a free hardware design that I’d happily work
> on :)
Sweet

> Reading and transmitting of the bitstream can be done in hardware alone
> (shift register, MUX, photoresistors, …), though I’d need to know what
> kind of interface there is on the receiving side.  Just flash memory /
> TTL shift register?
Well ultimately that would need to be a memory bus that is connected to
their TTL DRAM (64KB chips) or TTL SRAM (so we wouldn't have to worry
about memory refresh or other sort of issues like that)
and setting the memory address block starting from Zero until end of
deck.
The Memory is Big Endian Bit, Byte and Word Addressed.

The number address pins needs to be atleast 9 (otherwise the bootstrap
binaries would exceed the address space the reader could write to) and
not to exceed 64 (As I don't plan on implementing a 128bit ALU with
Floating point and Vector instructions needed to comply with the 128bit
version of the spec). I am planning on having the memory data bus to be
8bits wide as all instructions and datatypes are multiples of 8bits.

I can provide a clock signal for when the next value is to be loaded or
a line for you to directly drive the memory chips.

Or we could go the uart route and simply leverage a classic serial
connector.


> I?ve thought about this a bit.  Would it be possible to go even more
> mechanical, and implement the SPI protocol in switches toggled by holes
> cut in some kind of insulating tape?
Well that mechanical aspect would be what you would expect in punched
cards or paper tape (I was planning on doing a paper tape reader to
allow easier manual inspection of outputs, inputs and binaries)

> You could have a couple of steel
> balls (bearings?) balanced on top of each other, connected to a circuit
> using brushes or springs.  Then, you place the tape in between the
> bearings.  When there?s a hole in the insulating tape, they make
> contact, and when there is no hole, no contact.
Yep, classical through-hole reader technology. Not as reliable as
optical sensors but much more low tech and no room for anyone to insert
anything funny with the sensors.


> Then, you have a row of
> holes for the SPI clock, and a row of holes for the SPI data.  All you
> would have to do is hook up the right voltage to it, and you could write
> to a flash ROM by pulling manually punched tape through it.  (You could
> use a crank or motor if the timing needs to be more precise.)
Well you could have a hole aligned with the values being read (say a 9th
bit) which would trigger a clock pulse to indicate reading of the next byte.


> Then, you could take an x200 and setup the bootrom to be whatever you
> wanted with no software whatsoever.

Not possible, there is a 700+KB microcode blob in that CPU, without
which the CPU fails to power on for more than 10 clock cycles.

> If you adjusted stage0 to set up a
> ?cache-as-RAM? environment (like they do in coreboot), you could do
> quite a bit of manoeuvring before having to initialize RAM.
Well the 4MB of space (or 6MB if you have Penryn chip) is more than
enough to bootstrap cc_x86 and be able to compile a self-hosting C compiler


> That is,
> you could probably set up a tiny Scheme environment and do more hardware
> initialization from there.

Well the hardware initialization isn't a concern as that is currently
well documented in libreboot's code. The hard part is those computers
are only going to be working for a few more years before tin whiskers
kill the whole lot of them (the transistion to lead-free solder occurred
during that time) and then we will have a working solution to hardware
that is no longer available, no longer works and we can't build more
that will exactly match those specs without considerable effort.

> Obviously all of this would be easier on a simpler computer, but then
> presumably you have to move from a simpler computer to a more
> complicated computer at some point (depending on your needs).
I assume a 64bit processor with 16+GB of memory, a SATA interface and a
network interface should be sufficiently complicated to bootstrap
everything we will need to conern ourselves with in the next couple
years. (We can always enhance a design of our own making)

The Low end will be a 16bit processor with only 64KB of RAM and will
probably require ugly coding to fit some of the programs in that address size.

> The nice
> thing about booting the x200 as a simple computer is that you can just
> expand its boundaries until it is full-featured.
One needs to be precise by what one means by full-featured. Would you
consider Minix or Linux 1.0 a full-featured kernel? Would the ability to
build GCC and guile be considered full-featured enough? Because I can
build productive environments down to a hex0-monitor in a few hundred
bytes of total memory.

> Sorry for derailing a bit, I just wanted to share some idle thoughts.
I actively encourage alternative perspectives and I love being told
how I can do this better. I look forward to more ideas and suggestions
from you on this subject later ^_^

Just an open reminder our #bootstrappable channel is always looking for
people intersted in these sorts of topics and we love hearing about what
you have created in this regard.

-Jeremiah

^ permalink raw reply	[flat|nested] 23+ messages in thread
* Re: Preparing the reduced bootstrap tarballs
@ 2018-11-20  0:26 jeremiah
  2018-11-20  8:28 ` Ricardo Wurmus
  0 siblings, 1 reply; 23+ messages in thread
From: jeremiah @ 2018-11-20  0:26 UTC (permalink / raw)
  To: g, guix-devel

> so, if I don't get it wrong, every skilled engineer will be able to
> build an "almost analogic" (zero bit of software preloaded) computing
> machine ad use stage0/mes [1] as the "metre" [2] to calibrate all other
> computing machines (thanks to reproducible builds)?

well, I haven't thought of it in those terms but yes I guess that is one
of the properties of the plan.

> the first bit of code have to be "manually" introduced in the machine,
> right?
Correct, otherwise you'll have to deal with firmware/bios as a trust
vector to be concerned about.

> for the lazyer like me, what about a punched card? :-)
If someone is willing to figure out how to read a deck of punched cards
without software, I'd be interested in learning more.

> I didn't know about Nexus Intruder attacks: could you please give me
> some links to the relevant bibliography?
I'll see if I can dig those up for you.

> so, having the scientific proof that binary conforms to source, there
> will be noo need to trust (the untrastable)
Well, that is what someone else could do with it but not a direct goal
of the work.

-Jeremiah

^ permalink raw reply	[flat|nested] 23+ messages in thread
* Re: Preparing the reduced bootstrap tarballs
@ 2018-11-18 12:56 Jeremiah
  2018-11-18 18:27 ` Mark H Weaver
  0 siblings, 1 reply; 23+ messages in thread
From: Jeremiah @ 2018-11-18 12:56 UTC (permalink / raw)
  To: guix-devel

> However, my impression (correct me if I'm wrong) is that we are not yet
> able to bootstrap Guix exclusively from M2-Planet.
That is correct as the step of bootstrapping MesCC from M2-Planet is not
yet complete.
However once that is done, we can leverage Mes.c and gash to complete
the bootstrap of guix from that trusted reproducible source in a
reproducible fashion.

> For example, unless
> I'm mistaken, we still need Guile in our bootstrap, and I'm guessing
> that we are not yet able to build Guile exclusively from M2-Planet.
> Is that right?
We don't need it, so much as it is people wishing to avoid tedious work.
We already can bootstrap kaem without any shells or interpreters and it
can be used to run shell scripts that can perform the rest of the
bootstrap of a lisp or a proper shell.

I think because that work is less of a technical challenge that it has
been skipped.


> My only point is that if we cannot yet avoid blindly trusting
> precompiled binaries,

Depends on how restricted of an environment you ware willing to work in

> I have higher confidence in our 2013 binaries than
> in binaries we would produce today, because (1) we are more likely to be
> a target today because Guix has become far more popular, (2) I expect
> that intelligence agencies have far more advanced tools today than they
> did in 2013, and (3) I expect that governmental policies have become far
> more favorable to permitting such attacks against projects such as ours.

1) Granted
2) Not exactly; simply because the most advanced attack tool ever
invented was the Nexus Intruder Program in 1958. (Hardware that subverts
software that later subverts hardware designs and more software
[firmware, microcode, etc]). The tools might get more expensive but the
actual quality of attack tools depends on the teams and the market's
demand for pumping out vulnerable products and bugs. (Like the recent
Hard drive firmware attack which leveraged the vendor's cost cutting
process to hijack the drives and then lock out future attempts at
recovery.
3) Actually Government agencies are depending more and more on "Open
source tools" (Their words not mine) as software budgets have gotten
tighter and third party vendors integrate them more and more into their
commercial offerings purchased by Goverment agencies. Putting a backdoor
in the software most Government agencies depend upon, invites
vulnerabilities in our own Intelligence Agencies infrastructure and
increase the probablity that Spies will be identified before their
flight to their target country leaves the ground. To do such would not
only be suicidal for those Intelligence Agencies but also ensure
Cyberwarfare against the Countries they work for that much more
effective.

Now that isn't to say they consider that an extranality and doom us all
but nothing stays hidden when we can read the source and can DDC our
entire bootstrap across arbitrary hardware/operating system
combinations.

-Jeremiah

^ permalink raw reply	[flat|nested] 23+ messages in thread
* Re: Preparing the reduced bootstrap tarballs
@ 2018-11-17 14:27 Jeremiah
  2018-11-17 23:14 ` Mark H Weaver
  2018-11-19 18:54 ` Giovanni Biscuolo
  0 siblings, 2 replies; 23+ messages in thread
From: Jeremiah @ 2018-11-17 14:27 UTC (permalink / raw)
  To: guix-devel

> I think it's important that the new bootstrap-tarballs be
> bit-reproducible, such that they can be independently verified by anyone
> who wishes to do so.

Every Piece below M2-Planet has always been bit-reproducible.
In fact, each piece is designed in a way that you could by hand predict
what the resulting binary must be after any change.

and once I finally complete stage0; you would also have the blueprints
for making the virtual machine in hardware, hand toggle in the bits for
the hex0-monitor and have absolute proof that no trusting trust or Nexus
Intruder Class attacks have occurred in the creation of the binaries.

Every issue anyone is willing to bring, I will publicly address until
all bootstrap roots (even on arbitrary hardware) lead to the proof that
these binaries are perfectly reproducible and that they only behave in
the manner explicitly specified by the standards to which they conform.


> In particular, *I* would like to independently verify them, on my own
> laptops where I have avoided using binary substitutes for a long time,
> and which I keep with me at all times.
Already done; here are the steps currently for bootstrapping the
mescc-tools-seed and M2-Planet seed.M1:
git clone 'https://git.savannah.nongnu.org/git/stage0.git'
cd stage0
make test
cd ..
git clone 'https://git.savannah.nongnu.org/git/mescc-tools.git'
cd mescc-tools
make test
cd ..
git clone 'https://github.com/oriansj/mescc-tools-seed.git'
cd mescc-tools-seed
./bootstrap.sh sin

To generate the M2-Planet seed.M1 you need to either export
mescc-tools-seed's blood-elf, M1 and hex2 or mescc-tools (via copying
into your path or doing make install) then the steps to generate are as
follows:
git clone 'https://github.com/oriansj/M2-Planet.git'
cd M2-Planet
./bootstrap.sh refresh

Now you are done


> My hope until now is that when we generated our existing bootstrap
> binaries in 2013, Guix was too marginal a project to attract the
> attention of hackers who might wish to compromise our bootstrap.  In
> 2018, as Guix has become more popular, we might well be considered a
> worthy target of such efforts.

I like to go with the assumption that every binary is already
compromised; but by going back to the basics we can find and rip out
every single hook until we are finally secure.

I don't trust any hardware I can't or didn't make myself.
And the only root of trust we have is the ability to work as a
community, giving every member the ability to independently check our
assumptions and point out our mistakes. We will have false starts and
failures of imagination but we by working together will make us all a
dream that is too hard to achieve alone but easy now that we have each
other helping us all strive to a brighter future.

-Jeremiah

^ permalink raw reply	[flat|nested] 23+ messages in thread
* Re: Preparing the reduced bootstrap tarballs
@ 2018-11-15 20:39 Jeremiah
  2018-11-16 18:27 ` Ludovic Courtès
  0 siblings, 1 reply; 23+ messages in thread
From: Jeremiah @ 2018-11-15 20:39 UTC (permalink / raw)
  To: guix-devel



> Indeed.  "mes-seed" and "tinycc-seed" are remnants of the past; the only
> things we need are
>
>> What we would need here is something to build the things listed in
>> ‘%bootstrap-inputs’, namely:
>> ‘linux-libre-headers-stripped-4.14.26-i686-linux.tar.xz’ (easy :-)),
>> ‘mescc-tools-seed-XYZ.tar.gz’, and
>> ‘mes-stripped-0.18-0.08f04f5-i686-linux.tar.xz’

That is correct (With mescc-tools-seed adding steps and removing
binaries over time)

> So if you like, please make that change.  There is only one little
> thing: I have no (scripted) recipe to create mescc-tools-seed-XYZ.  But
> wait: I have a great excuse for that...I was too lazy or too sloppy.

I do, in mescc-tools-seed; the script bootstrap.sh when run with the
option "sin" will build the mescc-tools-seed binaries using mescc-tools.
The .M1 files are always generated by cc_x86.s using the C source files.


> The thing is, I used to build mescc-tools-seed, mes-seed and tinycc-seed
> manually from the mes+mescc+tinycc source trees.
I've been building them from the stage0 bootstrap tree (which as you can
see is rather trivial:
https://github.com/oriansj/talk-notes/blob/master/Current%20bootstrap%20map.dot
)


> Jeremiah Orians is
> working to remove any need for mescc-tools-seed (esp. the forward
> dependency on Mes) but I don't think we're there yet.
We have eliminated the forward dependency on Mes for the creation of the
mescc-tools-seed already


> Anyway, I think we/I will have to put some work into scripting
> mescc-tools-seed or otherwise changing the mescc-tools-boot build.
Already done in bash and kaem but not in guix yet (Should be trivial)

> WDYT?
I think we will end up having several versions of mescc-tools-seed; as
each architecture guix supports will end up needing a variant if we plan
on keeping them small. (I also have no idea how to make a multi-arch fat
elf binary)

I am also curious if there is any demand for the stripped versions of
mescc-tools-seed as those binaries are nearly half the size.

>> (do we really need an x86_64 version of this Mes?).
> No, I don't think so.  I added it esp. to get a preview and enable
> future development of pure x86_64 bootstrap; but dependency-wise we
> should be able to drop it!
also, AMD64 does support i386 binaries without issue

- Jeremiah

^ permalink raw reply	[flat|nested] 23+ messages in thread
* [bug#33038] [PATCH 1/6] doc: Move `Reduced Binary Seed Bootstrap' into `Bootstrapping'.
@ 2018-10-14  8:58 Jan Nieuwenhuizen
  2018-10-14  8:58 ` [bug#33038] [PATCH 3/6] bootstrap: Add %bootstrap-mes Jan Nieuwenhuizen
  0 siblings, 1 reply; 23+ messages in thread
From: Jan Nieuwenhuizen @ 2018-10-14  8:58 UTC (permalink / raw)
  To: 33038

* doc/guix.texi (Reduced Binary Seed Bootstrap):
---
 doc/guix.texi | 141 ++++++++++++++++++++++++++------------------------
 1 file changed, 72 insertions(+), 69 deletions(-)

diff --git a/doc/guix.texi b/doc/guix.texi
index a213a0324..48f01e989 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -210,7 +210,6 @@ GNU Distribution
 * Package Modules::             Packages from the programmer's viewpoint.
 * Packaging Guidelines::        Growing the distribution.
 * Bootstrapping::               GNU/Linux built from scratch.
-* Reduced Binary Seed Bootstrap::  A Bootstrap worthy of GNU.
 * Porting::                     Targeting another platform or kernel.
 
 System Installation
@@ -8695,7 +8694,6 @@ For information on porting to other architectures or kernels,
 * Package Modules::             Packages from the programmer's viewpoint.
 * Packaging Guidelines::        Growing the distribution.
 * Bootstrapping::               GNU/Linux built from scratch.
-* Reduced Binary Seed Bootstrap::  A Bootstrap worthy of GNU.
 * Porting::                     Targeting another platform or kernel.
 @end menu
 
@@ -23557,7 +23555,78 @@ re-create them if needed (more on that later).
 For @code{i686-linux} and @code{x86_64-linux} the Guix bootstrap process is
 more elaborate, @pxref{Reduced Binary Seed Bootstrap}.
 
-@unnumberedsubsec Preparing to Use the Bootstrap Binaries
+@menu
+* Reduced Binary Seed Bootstrap::  A Bootstrap worthy of GNU.
+* Preparing to Use the Bootstrap Binaries:: Building that what matters most.
+@end menu
+
+@node Reduced Binary Seed Bootstrap
+@subsection The Reduced Binary Seed Bootstrap
+
+Guix---like other GNU/Linux distributions---is traditionally bootstrapped from
+a set of bootstrap binaries: Bourne shell, command-line tools provided by GNU
+Coreutils, Awk, Findutils, `sed', and `grep' and Guile, GCC, Binutils, and the
+GNU C Library (@pxref{Bootstrapping}).  Usually, these bootstrap binaries are
+``taken for granted.''
+
+Taking these binaries for granted means that we consider them to be a correct
+and trustworthy `seed' for building the complete system.  Therein lies a
+problem: the current combined size of these bootstrap binaries is about 250MB
+(@pxref{Bootstrappable Builds,,, mes, Mes Reference Manual}).  Auditing or
+even inspecting these is next to impossible.
+
+For @code{i686-linux} and @code{x86_64-linux}, Guix now features a ``Reduced
+Binary Seed'' bootstrap @footnote{We would like to say: ``Full Source
+Bootstrap'' and while we are working towards that goal it would be hyperbole
+to use that term for what we do now.}.
+
+The Reduced Binary Seed bootstrap removes the most critical tools---from a
+trust perspective---from the bootstrap binaries: GCC, Binutils and the GNU C
+Library are replaced by: @code{mescc-tools-seed} (a tiny assembler and linker)
+@code{mes-seed} (a small Scheme Interpreter and a C compiler writen in Scheme)
+and @code{tinycc-seed} (the Mes C Library, built for TinyCC).  Using these new
+binary seeds and a new set of
+@c
+packages@footnote{@c
+mescc-tools-boot,
+nyacc-boot,
+mes-boot,
+tcc-boot0,
+tcc-boot,
+make-mesboot0,
+diffutils-mesboot,
+binutils-mesboot0,
+gcc-core-mesboot,
+mesboot-headers,
+glibc-mesboot0,
+gcc-mesboot0,
+binutils-mesboot,
+make-mesboot,
+gcc-mesboot1,
+gcc-mesboot1-wrapper,
+glibc-headers-mesboot,
+glibc-mesboot,
+gcc-mesboot,
+and
+gcc-mesboot-wrapper.
+}
+@c
+the ``missing'' Binutils, GCC, and the GNU C Library are built from source.
+From here on the more traditional bootstrap process resumes.  This approach
+has reduced the bootstrap binaries in size to about 130MB.  Work is ongoing to
+reduce this further.  If you are interested, join us on @code{#bootstrappable}
+on the Freenode IRC network.
+
+@c ./pre-inst-env guix graph --type=bag -e '(begin (use-modules (guix packages)) (%current-system "i686-linux") (@@ (gnu packages commencement) gcc-mesboot))' > doc/images/gcc-mesboot-bag-graph.dot
+@c dot -T png doc/images/gcc-mesboot-bag-graph.dot > doc/images/gcc-mesboot-bag-graph.png
+
+Below is the generated dependency graph for @code{gcc-mesboot}, the bootstrap
+compiler used to build the rest of GuixSD.
+
+@image{images/gcc-mesboot-bag-graph,6in,,Dependency graph of the gcc-mesboot}
+
+@node Preparing to Use the Bootstrap Binaries
+@subsection Preparing to Use the Bootstrap Binaries
 
 @c As of Emacs 24.3, Info-mode displays the image, but since it's a
 @c large image, it's hard to scroll.  Oh well.
@@ -23710,72 +23779,6 @@ bootstrap GCC with a sequence of assemblers, interpreters, and compilers
 of increasing complexity, which could be built from source starting from
 a simple and auditable assembler.  Your help is welcome!
 
-@node Reduced Binary Seed Bootstrap
-@section The Reduced Binary Seed Bootstrap
-
-Guix---like other GNU/Linux distributions---is traditionally bootstrapped from
-a set of bootstrap binaries: Bourne shell, command-line tools provided by GNU
-Coreutils, Awk, Findutils, `sed', and `grep' and Guile, GCC, Binutils, and the
-GNU C Library (@pxref{Bootstrapping}).  Usually, these bootstrap binaries are
-``taken for granted.''
-
-Taking these binaries for granted means that we consider them to be a correct
-and trustworthy `seed' for building the complete system.  Therein lies a
-problem: the current combined size of these bootstrap binaries is about 250MB
-(@pxref{Bootstrappable Builds,,, mes, Mes Reference Manual}).  Auditing or
-even inspecting these is next to impossible.
-
-For @code{i686-linux} and @code{x86_64-linux}, Guix now features a ``Reduced
-Binary Seed'' bootstrap @footnote{We would like to say: ``Full Source
-Bootstrap'' and while we are working towards that goal it would be hyperbole
-to use that term for what we do now.}.
-
-The Reduced Binary Seed bootstrap removes the most critical tools---from a
-trust perspective---from the bootstrap binaries: GCC, Binutils and the GNU C
-Library are replaced by: @code{mescc-tools-seed} (a tiny assembler and linker)
-@code{mes-seed} (a small Scheme Interpreter and a C compiler writen in Scheme)
-and @code{tinycc-seed} (the Mes C Library, built for TinyCC).  Using these new
-binary seeds and a new set of
-@c
-packages@footnote{@c
-mescc-tools-boot,
-nyacc-boot,
-mes-boot,
-tcc-boot0,
-tcc-boot,
-make-mesboot0,
-diffutils-mesboot,
-binutils-mesboot0,
-gcc-core-mesboot,
-mesboot-headers,
-glibc-mesboot0,
-gcc-mesboot0,
-binutils-mesboot,
-make-mesboot,
-gcc-mesboot1,
-gcc-mesboot1-wrapper,
-glibc-headers-mesboot,
-glibc-mesboot,
-gcc-mesboot,
-and
-gcc-mesboot-wrapper.
-}
-@c
-the ``missing'' Binutils, GCC, and the GNU C Library are built from source.
-From here on the more traditional bootstrap process resumes.  This approach
-has reduced the bootstrap binaries in size to about 130MB.  Work is ongoing to
-reduce this further.  If you are interested, join us on @code{#bootstrappable}
-on the Freenode IRC network.
-
-@c ./pre-inst-env guix graph --type=bag -e '(begin (use-modules (guix packages)) (%current-system "i686-linux") (@@ (gnu packages commencement) gcc-mesboot))' > doc/images/gcc-mesboot-bag-graph.dot
-@c dot -T png doc/images/gcc-mesboot-bag-graph.dot > doc/images/gcc-mesboot-bag-graph.png
-
-Below is the generated dependency graph for @code{gcc-mesboot}, the bootstrap
-compiler used to build the rest of GuixSD.
-
-@image{images/gcc-mesboot-bag-graph,6in,,Dependency graph of the gcc-mesboot}
-
-
 @node Porting
 @section Porting to a New Platform
 
-- 
2.18.0

^ permalink raw reply related	[flat|nested] 23+ messages in thread
end of thread, other threads:[~2018-11-26 18:49 UTC | newest]

Thread overview: 23+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2018-11-21  3:36 Preparing the reduced bootstrap tarballs Jeremiah
  -- strict thread matches above, loose matches on Subject: below --
2018-11-20  0:26 jeremiah
2018-11-20  8:28 ` Ricardo Wurmus
2018-11-18 12:56 Jeremiah
2018-11-18 18:27 ` Mark H Weaver
2018-11-18 18:39   ` Jan Nieuwenhuizen
2018-11-20 15:45     ` Timothy Sample
2018-11-21 20:32       ` Jan Nieuwenhuizen
2018-11-26 18:49         ` Timothy Sample
2018-11-17 14:27 Jeremiah
2018-11-17 23:14 ` Mark H Weaver
2018-11-19 18:54 ` Giovanni Biscuolo
2018-11-15 20:39 Jeremiah
2018-11-16 18:27 ` Ludovic Courtès
2018-11-16 20:44   ` Jan Nieuwenhuizen
2018-11-17 14:05     ` Ludovic Courtès
2018-11-18  7:32       ` Jan Nieuwenhuizen
2018-11-18 10:02         ` Jan Nieuwenhuizen
2018-11-17  3:49   ` Mark H Weaver
2018-10-14  8:58 [bug#33038] [PATCH 1/6] doc: Move `Reduced Binary Seed Bootstrap' into `Bootstrapping' Jan Nieuwenhuizen
2018-10-14  8:58 ` [bug#33038] [PATCH 3/6] bootstrap: Add %bootstrap-mes Jan Nieuwenhuizen
2018-10-19 21:31   ` Ludovic Courtès
2018-10-20  7:35     ` Jan Nieuwenhuizen
2018-10-21 21:09       ` Ludovic Courtès
2018-10-21 21:32         ` Jan Nieuwenhuizen
2018-10-23 21:00           ` bug#33038: " Jan Nieuwenhuizen
2018-11-15  9:06             ` Preparing the reduced bootstrap tarballs Ludovic Courtès
2018-11-15 15:44               ` Jan Nieuwenhuizen
2018-11-16 18:22                 ` Ludovic Courtès
2018-11-16 20:52                   ` Jan Nieuwenhuizen

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.