swig failure on aarch64 on core-updates

[Efraim Flashner]

From the build log with --cores=1

checking guile testcase template_whitespace
checking guile testcase threads
checking guile testcase threads_exception
checking guile testcase throw_exception (with run test)
free(): invalid pointer
/gnu/store/3dzvi613nf3fz42rabksw6svslvanfz7-bash-minimal-4.4.23/bin/sh: line 1: 
21784 Aborted (core dumped) env GUILE_AUTO_COMPILE=0 
LD_LIBRARY_PATH=.:$LD_LIBRARY_PATH 
/gnu/store/7pb9ywfzvr8jwgykpj52vfd8d6kimc3w-guile-2.0.14/bin/guile -l .
/throw_exception_runme.scm
make[1]: *** [Makefile:36: throw_exception.cpptest] Error 134
checking guile testcase typedef_array_member
checking guile testcase typedef_class
checking guile testcase typedef_funcptr
checking guile testcase typedef_inherit (with run test)
checking guile testcase typedef_mptr

I don't see anything upstream about this, so I figured I'd post it here
first. This happens with and without the fix-swig-for-i686 patch.

-- 
Efraim Flashner  אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

Re: Preparing the reduced bootstrap tarballs

[Jan Nieuwenhuizen]

Ludovic Courtès writes:

Hi!

>> Still I hope these won't last for five more years ;-)
>
> Well I hope these will last for at least a couple of years, or at least
> this is what we should aim for.

Yes, we should aim for that while creating them.  I'm possibly a bit too
eager to replace the reduced binary seed bootstrap by a scheme only
bootstrap and reduce all of our seeds even further.

> Replacing bootstrap binaries is not anecdotal as I wrote because these
> are “binary blobs” that need a special procedure to verify them; that
> they are smaller blobs is of course a crucial improvement, but it
> doesn’t change the fact that one may want to verify them.

Fully agree.

> As discussed yesterday on IRC, please also make sure make-bootstrap.scm
> does not refer to (gnu packages bootstrap) at all since that would be
> like running in circles.

Thank you.  Right, that's fixed now.

> As discussed just now on IRC, we probably also need #:system
> "i686-linux" in the appropriate places such that “guix build
> bootstrap-tarballs” gives the same result on i686 and on x86_64.

I'm looking into that right now.

>> From cc3782c5f9d2c606a265be0dfdca44d79ec25622 Mon Sep 17 00:00:00 2001
>> From: Jan Nieuwenhuizen 
>> Date: Fri, 16 Nov 2018 21:30:00 +0100
>> Subject: [PATCH 2/3] bootstrap: Add %bootstrap-mescc-tools.
>>
>> Built with
>> 5702107a31f52a615c516084b7a82d9f5e2967e0 bootstrap: Add 
>> mescc-tools-static, mescc-tools-static-tarball.
>>
>> * gnu/packages/bootstrap.scm (%bootstrap-mescc-tools): New variable.
>
> OK.
>
> If you want, before pushing this patch, you can first push the one
> above.  From there I (and possibly others!) will run “guix build
> bootstrap-tarballs” and make sure we get the same result as you did.

Great, done.  I missed

5b01b6034aeab32a5011c5757f18bd9772d3497d python: Honor '--cores=...' in 
tests.

happening yesterday; so pushed as

fae3c0d953a7b0b552b4ce654ed9b5a51186f491
bootstrap: Add mescc-tools-static, mescc-tools-static-tarball.

Note you'll also need something like these three extra commits

--8<---cut here---start->8---
2d8f7e2ac bootstrap: Update %bootstrap-tarballs.
57fbf077a bootstrap: Replace %mescc-tools-seed with %bootstrap-mescc-tools.
706574ee4 bootstrap: Add %bootstrap-mescc-tools.
--8<---cut here---end--->8---

from core-updates-next @ https://gitlab.com/janneke/guix to be able to
build `guix --system=i686-linux bootstrap-tarballs'.  Until then, the
recipe is

--8<---cut here---start->8---
./pre-inst-env guix build --system=i686-linux mes-stripped-tarball 
mescc-tools-static-tarball
--8<---cut here---end--->8---

Rebuilding that right now, let's compare what we get.

Thanks for all your input!
janneke

-- 
Jan Nieuwenhuizen  | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com

Re: Come back and graphical installer

[Mathieu Othacehe]

Hey,

> Here they are:
>
> /gnu/store/xlsn612abqz25gl0bxdxdpax9z8ngaxn-module-import
> ├── gnu
> │ └── installer

Ok, so its where the problem is, somehow scheme-modules in the 'modules'
procedure of (gnu installer newt) fails to load most of the modules. I
don't really understand why, plus I can't reproduce it :(

I replaced scheme-modules -> scheme-modules* in 0c4dcc187. If you could
fetch the branch and try to build a new disk-image, it would be great!

Thanks in advance,

Mathieu

Re: Preparing the reduced bootstrap tarballs

[Mark H Weaver]

Hi Jeremiah,

jerem...@pdp10.guru writes:

>> 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.

Sure, and I'm glad to hear this.

However, my impression (correct me if I'm wrong) is that we are not yet
able to bootstrap Guix exclusively from M2-Planet.  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?

>> 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;

I agree.  I didn't mean to imply that I consider our 2013 bootstrap
binaries trustworthy.  I very much look forward to the day when I
needn't blindly trust any precompiled binaries at all.

My only point is that if we cannot yet avoid blindly trusting
precompiled binaries, 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.

> 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.

I very much appreciate your work on this, which is quite important.

 Regards,
   Mark

Re: libvirt with modified QEMU and OVMF

[Lars Böckel]

So to follow this up now. I tried these: 
 (simple-service 'qemu-conf etc-service-type
   `(("libvirt/qemu.conf"
  ,(mixed-text-file "qemu.conf"
 "nvram
= /run/current-system/profile/share/firmware/ovmf_x64.bin \n
user='1000'"

(extra-special-file "/etc/libvirt/qemu.conf"
(plain-file
  "etc/libvirt/qemu.conf"
 "nvram
= /run/current-system/profile/share/firmware/ovmf_x64.bin \n
user='1000'"))


also i tried to edit the libvirt package by doing this:
 (replace 'install
   ;; Since the sysconfdir and localstatedir should be /etc
and /var ;; at runtime, we must prevent writing to them at installation
   ;; time.
   (lambda _
 (invoke "make" "install"
"sysconfdir=/tmp/etc"
"localstatedir=/tmp/var")))
 (add-after 'install 'ovmf-stuff
   (lambda* (#:key outputs #:allow-other-keys)
 (let* ((output (assoc-ref outputs "out"))
(etclibvirt (string-append output "/etc/libvirt")))
   (mkdir-p etclibvirt)
   (with-output-to-file
   (string-append etclibvirt "/qemu.conf")
 (lambda _
   (format #t
   "nvram
= /run/current-system/profile/share/firmware/ovmf_x64.bin user='1000'"
   output))

 (add-after 'ovmf-stuff 'wrap-libvirtd
   (lambda* (#:key inputs outputs #:allow-other-keys)
 (let ((out (assoc-ref outputs "out")))
   (wrap-program (string-append out "/sbin/libvirtd")
 `("PATH" = (,(string-append (assoc-ref inputs
 "iproute") "/sbin")
 ,(string-append (assoc-ref inputs "qemu")
 "/bin"

i really hope that after my mail client butchered it it is still
readable. to summarize: an etc-service-type will not work because it
links to /etc/libvirt which alredy exist and an extra-special-file will
not work because "invalid character `/' in name
`etc/libvirt/qemu.conf'". The file created in the package does not
exist in /etc but in /run/current-system/profile/etc where libvirt
probably does not read. At least it does not work as expected. 





> Thanks for sharing your idea about it. I cannot pull right now but i 
> think ...nvram = " ovmf "/F... would not work since you would have to 
> call the complete path of the package. Though something like "nvram = 
> /run/current-system/profile/share/firmware/ovmf_x64.bin" COULD work.
> I don't know how it would react to the massive wall of symlinks. That
> is probably the reason why NixOS calls it with ${pkgs.OVMF}. The
> produced file in NixOS (/var/lib/libvirt/qemu.conf) points
> to /nix/store/ For usability something you can just put in
> libvirt-service-type with #t would be good for usability. As well as
> the user variable. Configurations like these are probably more common
> than changing tls-ports and would simplify the migration of people
> running different systems since they could more easily configure VMs
> with UEFI support.
> 
> When my internet is running again i will pull and try this config.
> But since its saturday that might take some time... You can easily
> check for UEFI support in libvirt with either virt-install --boot
> uefi or in virt-manager when you create a vm and edit it beforehand
> you have a dropdown menu for BIOS/UEFI. If someone could test it out
> and report back that would be great!
> 
>   
> >> i would like to push the issue with OVMF in libvirt again:
> >>
> >> I would like to have OVMF(UEFI) capability with QEMU. In NixOS you
> >> can achieve this with
> >>
> >>    virtualisation.libvirtd.enable = true;
> >>    virtualisation.libvirtd.qemuOvmf = true;
> >>     virtualisation.libvirtd.qemuVerbatimConfig = ''
> >>   nvram =
> >> [ "${pkgs.OVMF}/FV/OVMF.fd:${pkgs.OVMF}/FV/OVMF_VARS.fd" ] user =
> >> "1000" '';
> >>
> >> the "user" part is not necessary but is required for system VMs in
> >> combination with qemu's pulseaudio driver. qemuVerbatimConfig is
> >> the config that is at /etc/libvirt/qemu.conf in traditional
> >> GNU/Linux distributions.
> > I don’t know about OVMF but IIUC, what you need here is to create
> > /etc/libvirt/qemu.conf.  To do that, you can something along these
> > lines:
> >
> >(simple-service 'qemu-conf etc-service-type
> >`(("libvirt/qemu.conf"
> >   ,(mixed-text-file "qemu.conf"
> >  "nvarm = "
> >  ovmf "/FV/OVMF.fd:…'
> >
> > Would that work?
> >
> > (Actually the “libvirt/” bit is only possible since commit
> > 5dec93bb8ba89605bce2f9a5ee9c4dbadeee3b58, a few minutes ago…)
> >
> > We could provide a proper abstr

Re: libvirt with modified QEMU and OVMF

[Lars Böckel]

So to follow this up now. I tried these: 
 (simple-service 'qemu-conf etc-service-type
   `(("libvirt/qemu.conf"
  ,(mixed-text-file "qemu.conf"
 "nvram
= /run/current-system/profile/share/firmware/ovmf_x64.bin \n
user='1000'"

(extra-special-file "/etc/libvirt/qemu.conf"
(plain-file
  "etc/libvirt/qemu.conf"
 "nvram
= /run/current-system/profile/share/firmware/ovmf_x64.bin \n
user='1000'"))


also i tried to edit the libvirt package by doing this:
 (replace 'install
   ;; Since the sysconfdir and localstatedir should be /etc
and /var ;; at runtime, we must prevent writing to them at installation
   ;; time.
   (lambda _
 (invoke "make" "install"
"sysconfdir=/tmp/etc"
"localstatedir=/tmp/var")))
 (add-after 'install 'ovmf-stuff
   (lambda* (#:key outputs #:allow-other-keys)
 (let* ((output (assoc-ref outputs "out"))
(etclibvirt (string-append output "/etc/libvirt")))
   (mkdir-p etclibvirt)
   (with-output-to-file
   (string-append etclibvirt "/qemu.conf")
 (lambda _
   (format #t
   "nvram
= /run/current-system/profile/share/firmware/ovmf_x64.bin user='1000'"
   output))

 (add-after 'ovmf-stuff 'wrap-libvirtd
   (lambda* (#:key inputs outputs #:allow-other-keys)
 (let ((out (assoc-ref outputs "out")))
   (wrap-program (string-append out "/sbin/libvirtd")
 `("PATH" = (,(string-append (assoc-ref inputs
 "iproute") "/sbin")
 ,(string-append (assoc-ref inputs "qemu")
 "/bin"

i really hope that after my mail client butchered it it is still
readable. to summarize: an etc-service-type will not work because it
links to /etc/libvirt which alredy exist and an extra-special-file will
not work because "invalid character `/' in name
`etc/libvirt/qemu.conf'". The file created in the package does not
exist in /etc but in /run/current-system/profile/etc where libvirt
probably does not read. At least it does not work as expected. 





> Thanks for sharing your idea about it. I cannot pull right now but i 
> think ...nvram = " ovmf "/F... would not work since you would have to 
> call the complete path of the package. Though something like "nvram = 
> /run/current-system/profile/share/firmware/ovmf_x64.bin" COULD work.
> I don't know how it would react to the massive wall of symlinks. That
> is probably the reason why NixOS calls it with ${pkgs.OVMF}. The
> produced file in NixOS (/var/lib/libvirt/qemu.conf) points
> to /nix/store/ For usability something you can just put in
> libvirt-service-type with #t would be good for usability. As well as
> the user variable. Configurations like these are probably more common
> than changing tls-ports and would simplify the migration of people
> running different systems since they could more easily configure VMs
> with UEFI support.
> 
> When my internet is running again i will pull and try this config.
> But since its saturday that might take some time... You can easily
> check for UEFI support in libvirt with either virt-install --boot
> uefi or in virt-manager when you create a vm and edit it beforehand
> you have a dropdown menu for BIOS/UEFI. If someone could test it out
> and report back that would be great!
> 
> 
> >> i would like to push the issue with OVMF in libvirt again:
> >>
> >> I would like to have OVMF(UEFI) capability with QEMU. In NixOS you
> >> can achieve this with
> >>
> >>    virtualisation.libvirtd.enable = true;
> >>    virtualisation.libvirtd.qemuOvmf = true;
> >>     virtualisation.libvirtd.qemuVerbatimConfig = ''
> >>   nvram =
> >> [ "${pkgs.OVMF}/FV/OVMF.fd:${pkgs.OVMF}/FV/OVMF_VARS.fd" ] user =
> >> "1000" '';
> >>
> >> the "user" part is not necessary but is required for system VMs in
> >> combination with qemu's pulseaudio driver. qemuVerbatimConfig is
> >> the config that is at /etc/libvirt/qemu.conf in traditional
> >> GNU/Linux distributions.  
> > I don’t know about OVMF but IIUC, what you need here is to create
> > /etc/libvirt/qemu.conf.  To do that, you can something along these
> > lines:
> >
> >(simple-service 'qemu-conf etc-service-type
> >`(("libvirt/qemu.conf"
> >   ,(mixed-text-file "qemu.conf"
> >  "nvarm = "
> >  ovmf "/FV/OVMF.fd:…'
> >
> > Would that work?
> >
> > (Actually the “libvirt/” bit is only possible since commit
> > 5dec93bb8ba89605bce2f9a5ee9c4dbadeee3b58, a few minutes ago…)
> >
> > We could provide a proper abstracti

Re: Come back and graphical installer

[L p R n d n]

No problem. ;)

Here they are:

/gnu/store/xlsn612abqz25gl0bxdxdpax9z8ngaxn-module-import
├── gnu
│   └── installer
│   ├── connman.scm
│   ├── newt
│   │   ├── page.scm
│   │   ├── utils.scm
│   │   └── wifi.scm
│   ├── steps.scm
│   └── utils.scm
└── guix
├── build
│   └── utils.scm
├── config.scm
├── i18n.scm
└── records.scm

5 directories, 10 files

and

/gnu/store/g967vsq3dix4w5zjhpcp9p4f30hcmnsm-module-import-compiled
├── gnu
│   └── installer
│   ├── connman.go
│   ├── newt
│   │   ├── page.go
│   │   ├── utils.go
│   │   └── wifi.go
│   ├── steps.go
│   └── utils.go
└── guix
├── build
│   └── utils.go
├── config.go
├── i18n.go
└── records.go

5 directories, 10 files

Lprndn

Re: 03/04: gnu: Add git-when-merged.

[Kyle Meyer]

Mark H Weaver  writes:

>> * gnu/packages/version-control.scm (git-when-merged): New variable.

[...]

> The license field of this package is incorrect.  It has this:
>
>   (license license:gpl2)
>
> which is understandable given that GitHub shows the license as "GPL-2.0"
> on the main project page .
> However, if you look at the actual code, there's only one source file
> and it has a proper GNU GPLv2+ copyright notice at the top.

Sorry about that, and thanks for spotting my mistake.  I'm happy to send
a patch to guix-patches, but I imagine it is easier for someone with
push access to correct it.

-- 
Kyle

Re: cmake build system 'ld: cannot find -lpthreads' (OpenClonk)

[Tonton]

On Sat, 17 Nov 2018 16:23:47 +0100
Tonton  wrote:

> The relevant errors I get here are:
> /tmp/guix-build-openclonk-8.1.drv-0/build/CMakeFiles/CMakeError.log:
> 
> Linking C executable cmTC_e2823
> /gnu/store/g85ikfjxs2d7aydvg5w06jn2h9xrjmpc-cmake-3.11.0/bin/cmake -E
>   cmake_link_script CMakeFiles/cmTC_e2823.dir/link.txt --verbose=1 
> /gnu/store/zrhwhlqqk51qslbddk4cip2z2p3fpvxd-gcc-5.5.0/bin/gcc
>   -DCHECK_FUNCTION_EXISTS=pthread_create-rdynamic
>   CMakeFiles/cmTC_e2823.dir/CheckFunctionExists.c.o  -o cmTC_e2823
>   -lpthreads
> ld: cannot find -lpthreads
> collect2: error: ld returned 1 exit status
> 


I should add that cmake's configure and the compilation phase seems to find
pthreads. I looked through the log and found the following though:
/tmp/guix-build-openclonk-8.1.drv-0/build/CMakeFiles/CMakeOutput.log:

Determining if the function pthread_create exists in the pthread passed with
the following output:
Change Dir: /tmp/guix-build-openclonk-8.1.drv-0/build/CMakeFiles/CMakeTmp

Run Build
Command:"/gnu/store/nx21fqlb8jixwhbs83xlfp9a3h5p3g9a-make-4.2.1/bin/make"
"cmTC_56777/fast"
/gnu/store/nx21fqlb8jixwhbs83xlfp9a3h5p3g9a-make-4.2.1/bin/make
-f CMakeFiles/cmTC_56777.dir/build.make
CMakeFiles/cmTC_56777.dir/build
make[1]: Entering directory
'/tmp/guix-build-openclonk-8.1.drv-0/build/CMakeFiles/CMakeTmp'
Building C object CMakeFiles/cmTC_56777.dir/CheckFunctionExists.c.o
/gnu/store/zrhwhlqqk51qslbddk4cip2z2p3fpvxd-gcc-5.5.0/bin/gcc
-DCHECK_FUNCTION_EXISTS=pthread_create   -o
CMakeFiles/cmTC_56777.dir/CheckFunctionExists.c.o
-c 
/gnu/store/g85ikfjxs2d7aydvg5w06jn2h9xrjmpc-cmake-3.11.0/share/cmake-3.11/Modules/CheckFunctionExists.c
Linking C executable cmTC_56777
/gnu/store/g85ikfjxs2d7aydvg5w06jn2h9xrjmpc-cmake-3.11.0/bin/cmake
-E cmake_link_script CMakeFiles/cmTC_56777.dir/link.txt
--verbose=1
/gnu/store/zrhwhlqqk51qslbddk4cip2z2p3fpvxd-gcc-5.5.0/bin/gcc
-DCHECK_FUNCTION_EXISTS=pthread_create-rdynamic
CMakeFiles/cmTC_56777.dir/CheckFunctionExists.c.o  -o cmTC_56777
-lpthread
make[1]: Leaving directory
'/tmp/guix-build-openclonk-8.1.drv-0/build/CMakeFiles/CMakeTmp'

---

Does 'make[1]: ' mean return status 1 - e.g. failed? I guess. If so why
does it succed compiling...

cmake build system 'ld: cannot find -lpthreads' (OpenClonk)

[Tonton]

I've been trying to define and build openclonk, but I keep getting build
failures because pthreads are missing.

tl;dr: how to make pthreads work with cmake-build-system for linking...

I have grepped the guix sources for pthreads but I can't seem to find it
explicitly declared used. And AFAIK pthreads is part of gcc, stdc or glib or
something; I seem to remember only needing to tack on the -lpthreads flag on
the compiler when I was playing with it, no extra packages.

So I'm a bit at a loss. Maybe this is a quirk with cmake or how openclonk
uses cmake; though it seems they are doing the necessary steps in their
cmakelists.txt

The definition I'm working on can be found at the following link. I apologize
in advance for the cluttered file - it's basically my playroom (I have some
work in front of me to declutter and send patches with the definitions that
work from here - in the future).

https://notabug.org/thomassgn/guixsd-configuration/src/master/modules/ton-tull.scm#L571

The relevant errors I get here are:
/tmp/guix-build-openclonk-8.1.drv-0/build/CMakeFiles/CMakeError.log:

Linking C executable cmTC_e2823
/gnu/store/g85ikfjxs2d7aydvg5w06jn2h9xrjmpc-cmake-3.11.0/bin/cmake -E
cmake_link_script CMakeFiles/cmTC_e2823.dir/link.txt --verbose=1 
/gnu/store/zrhwhlqqk51qslbddk4cip2z2p3fpvxd-gcc-5.5.0/bin/gcc
-DCHECK_FUNCTION_EXISTS=pthread_create-rdynamic
CMakeFiles/cmTC_e2823.dir/CheckFunctionExists.c.o  -o cmTC_e2823
-lpthreads
ld: cannot find -lpthreads
collect2: error: ld returned 1 exit status

Re: Come back and graphical installer

[Mathieu Othacehe]

> Here it is!

Thanks, it seems pretty ok. One last request, could you execute those
two commands and send me the result?

tree /gnu/store/xlsn612abqz25gl0bxdxdpax9z8ngaxn-module-import
tree /gnu/store/g967vsq3dix4w5zjhpcp9p4f30hcmnsm-module-import-compiled 

Sorry for the hassle,

Mathieu

Re: Preparing the reduced bootstrap tarballs

[Jeremiah]

> 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

Getting ‘core-updates’ merged

[Ludovic Courtès]

Hi!

Björn Höfling  skribis:

> On Fri, 16 Nov 2018 22:20:27 +0100
> l...@gnu.org (Ludovic Courtès) wrote:
>> Ricardo Wurmus  skribis:

[...]

>> > I would prefer to have core-updates in the next release.  This has
>> > been delayed for much too long.  This would also avoid the bad look
>> > for a new release to have somewhat outdated core packages.
>> >
>> > If we can’t get core-updates ready within the next few weeks I won’t
>> > object to a release without it, but I think we should really try.  
>> 
>> Yes, that makes sense to me.
>> 
>> So everyone: let’s join forces and get ‘core-updates’ finally merged!
>
> What is to do for core-updates to succeed? Is it "just" that
> hydra/berlin need to build it, or is there anything a human being can
> do (Or is the former necessary to define the latter?)?
>
> Is there a list of open/unresolved tasks?

What remains to be done is mostly (1) ensuring that there’s no
significant regression in terms of build failures compared to ‘master’,
and (2) making sure GuixSD boots and works fine.

For #1, a simple test is to try and upgrade your profile and see if
everything builds and works well.  In addition, you can look at these
dashboards to identify build failures that need to be addressed:

  https://hydra.gnu.org/jobset/gnu/core-updates
  https://berlin.guixsd.org/jobset/core-updates-core-updates

For #2, running “make check-system”, or at least the inexpensive subset
of system tests (the expensive tests are the installation tests) should
give a good overview—Mark already reported an issue at
.  The next step of course is to
try it on the bare metal for your own system config.

If we all do our share of testing, this can actually be pretty fast.
If today is a rainy day, here’s a good activity for you!  :-)

Thanks,
Ludo’.

Re: Come back and graphical installer

[L p R n d n]

Mathieu Othacehe  writes:

>> I built the disk image from the wip-newt-installer branch.
>
> Ok so could you run:
>
> guix gc -R /gnu/store/xxx-your-disk-image | grep installer
>
> It should return you the installer script in store
> (/gnu/store/xxx-installer). Replying to this email with this file in
> attachment would maybe help me understand what's going wrong.
>
> Thanks,
>
> Mathieu

Here it is!

Thanks,

Lprndn


installer
Description: Binary data

Re: Preparing the reduced bootstrap tarballs

[Ludovic Courtès]

Hello,

Jan Nieuwenhuizen  skribis:

>> IMO we should change the seeds as rarely as possible because they are
>> managed “out-of-band” and verifying them is difficult (you need to fetch
>> the right Guix commit, run “guix build bootstrap-tarballs”, and compare
>> the result—assuming this is all bit-reproducible.)
>>
>> The one we’re using today in Guix date back to 2013.
>
> Okay, I am proposing the attached patches, also available on my 
> core-updates-next at http://gitlab.com/janneke/guix
>
> Still I hope these won't last for five more years ;-)

Well I hope these will last for at least a couple of years, or at least
this is what we should aim for.

Replacing bootstrap binaries is not anecdotal as I wrote because these
are “binary blobs” that need a special procedure to verify them; that
they are smaller blobs is of course a crucial improvement, but it
doesn’t change the fact that one may want to verify them.

> From 5702107a31f52a615c516084b7a82d9f5e2967e0 Mon Sep 17 00:00:00 2001
> From: Jan Nieuwenhuizen 
> Date: Fri, 16 Nov 2018 19:29:55 +0100
> Subject: [PATCH 1/3] bootstrap: Add mescc-tools-static,
>  mescc-tools-static-tarball.
>
> * gnu/packages/make-bootstrap.scm (%mescc-tools-static,
> %mescc-tools-bootstrap-tarball):  New variable.

Neat; I’m glad it was as simple as this.  :-)

As discussed yesterday on IRC, please also make sure make-bootstrap.scm
does not refer to (gnu packages bootstrap) at all since that would be
like running in circles.

As discussed just now on IRC, we probably also need #:system
"i686-linux" in the appropriate places such that “guix build
bootstrap-tarballs” gives the same result on i686 and on x86_64.

> From cc3782c5f9d2c606a265be0dfdca44d79ec25622 Mon Sep 17 00:00:00 2001
> From: Jan Nieuwenhuizen 
> Date: Fri, 16 Nov 2018 21:30:00 +0100
> Subject: [PATCH 2/3] bootstrap: Add %bootstrap-mescc-tools.
>
> Built with
> 5702107a31f52a615c516084b7a82d9f5e2967e0 bootstrap: Add 
> mescc-tools-static, mescc-tools-static-tarball.
>
> * gnu/packages/bootstrap.scm (%bootstrap-mescc-tools): New variable.

OK.

If you want, before pushing this patch, you can first push the one
above.  From there I (and possibly others!) will run “guix build
bootstrap-tarballs” and make sure we get the same result as you did.

> From daa9ff9463917687aabed8330eacb304a7e4deae Mon Sep 17 00:00:00 2001
> From: Jan Nieuwenhuizen 
> Date: Fri, 16 Nov 2018 21:30:28 +0100
> Subject: [PATCH 3/3] bootstrap: Replace %mescc-tools-seed with
>  %bootstrap-mescc-tools.
>
> * gnu/packages/bootstrap.scm (%mescc-tools-seed): Remove.
> (%bootstrap-inputs): Replace %mescc-tools-seed with %bootstrap-mescc-tools.
> * gnu/packages/commencement.scm (mes-boot): Likewise.

Also: (mescc-tools-boot): Remove.

> (tcc-boot0): Likewise.
> (mescc-tools-boot): Remove.

I suppose this is not directly related to the other changes, but anyway,
LGTM.

Thanks for the quick reply!

Ludo’.

Re: Come back and graphical installer

[Mathieu Othacehe]

> I built the disk image from the wip-newt-installer branch.

Ok so could you run:

guix gc -R /gnu/store/xxx-your-disk-image | grep installer

It should return you the installer script in store
(/gnu/store/xxx-installer). Replying to this email with this file in
attachment would maybe help me understand what's going wrong.

Thanks,

Mathieu

Re: Come back and graphical installer

[L p R n d n]

Hey,

I built the disk image from the wip-newt-installer branch.

Lprndn

Re: Come back and graphical installer

[Mathieu Othacehe]

Hey,

Thanks for trying to test :)

> "ERROR: In procedure scm-error:
> no code for module (gnu installer keymap)"

Was it with the iso-image from google-drive or did you build the
installer from wip-installer-branch ?

Mathieu

Re: Come back and graphical installer

[L p R n d n]

Hello,

Tryed to test the installer this morning, like instructed in Matthieu's
message but I'm getting an error.
The message is cycling (showing/unshowing) so here are the last lines.

"ERROR: In procedure scm-error:
no code for module (gnu installer keymap)"

Couldn't interact with the vm so I join a *nicely* timed screenshot
whit the full error.

Lprndn

Re: 03/04: gnu: Add git-when-merged.

[Mark H Weaver]

Hi Kyle and Ludovic,

l...@gnu.org (Ludovic Courtès) writes:

> civodul pushed a commit to branch master
> in repository guix.
>
> commit 243bdcc12e40c8dbd1129fa5b613d8f247744f31
> Author: Kyle Meyer 
> Date:   Mon Nov 12 16:24:23 2018 -0500
>
> gnu: Add git-when-merged.
> 
> * gnu/packages/version-control.scm (git-when-merged): New variable.
> 
> Signed-off-by: Ludovic Courtès 
> ---
>  gnu/packages/version-control.scm | 52 
> 
>  1 file changed, 52 insertions(+)

The license field of this package is incorrect.  It has this:

  (license license:gpl2)

which is understandable given that GitHub shows the license as "GPL-2.0"
on the main project page .
However, if you look at the actual code, there's only one source file
and it has a proper GNU GPLv2+ copyright notice at the top.

  https://github.com/mhagger/git-when-merged/blob/master/bin/git-when-merged

The only other files in the repository are README.md and COPYING.

A lesson here is that we cannot trust the GitHub license information, or
at least that we should we suspicious when we see "GPL-2.0".

  Mark


> diff --git a/gnu/packages/version-control.scm 
> b/gnu/packages/version-control.scm
> index 04d2804..fd90513 100644
> --- a/gnu/packages/version-control.scm
> +++ b/gnu/packages/version-control.scm
> @@ -2279,3 +2279,55 @@ used to keep a folder in sync between computers.")
>  ;; The web app is released under the AGPLv3+.
>  (license (list license:gpl3+
> license:agpl3+
> +
> +(define-public git-when-merged
> +  ;; Use an unreleased version to get a PY3 compatibility fix.
> +  (let ((commit "ab6af7865a0ba55ba364a6c507e0be6f84f31c6d"))
> +(package
> +  (name "git-when-merged")
> +  (version (string-append "1.2.0-" (string-take commit 7)))
> +  (source (origin
> +(method git-fetch)
> +(uri (git-reference
> +  (url "https://github.com/mhagger/git-when-merged/";)
> +  (commit commit)))
> +(file-name (git-file-name name version))
> +(sha256
> + (base32
> +  "0iyk2psf97bc9h43m89p3xjmm79fsx99i7px29g4lcnmdy5kmz0p"
> +  (build-system gnu-build-system)
> +  (arguments
> +   `(#:tests? #f; there are no tests
> + #:phases
> + (modify-phases %standard-phases
> +   (delete 'configure)
> +   (delete 'build)
> +   (replace 'install
> + (lambda* (#:key outputs #:allow-other-keys)
> +   (install-file "bin/git-when-merged"
> + (string-append (assoc-ref outputs "out")
> +"/bin"))
> +   #t))
> +   (add-before 'install 'patch-git
> + (lambda* (#:key inputs #:allow-other-keys)
> +   (let ((git (string-append (assoc-ref inputs "git")
> + "/bin/git")))
> + (substitute* "bin/git-when-merged"
> +   (("'git'") (string-append "'" git "'")))
> + #t)))
> +   (add-after 'install 'wrap-script
> + (lambda* (#:key outputs #:allow-other-keys)
> +   (wrap-program (string-append (assoc-ref outputs "out")
> +"/bin/git-when-merged")
> + `("PYTHONPATH" ":" prefix (,(getenv "PYTHONPATH"
> +   #t)
> +  (inputs
> +   `(("git" ,git)
> + ("python" ,python-wrapper)))
> +  (home-page "https://github.com/mhagger/git-when-merged";)
> +  (synopsis "Determine when a commit was merged into a Git branch")
> +  (description "This Git extension defines a subcommand,
> +@code{when-merged}, whose core operation is to find the merge that brought a
> +given commit into the specified ref(s).  It has various options that control
> +how information about the merge is displayed.")
> +  (license license:gpl2