Re: CDN performance
Hi Chris,
Chris Marusich writes:
> Meiyo Peng writes:
>
>> After careful thought, I realized the new CDN won't benefit China
>> residents as planned. Any popular CDN outside China is significantly
>> throttled by ISP/GFW and the situation is worse every year. A CDN will
>> be a great improvement for western countries but not for many asia
>> countries.
>
> Could you try running the measure_get shell function I included in the
> following email?
>
> https://lists.gnu.org/archive/html/guix-devel/2018-12/msg00192.html
>
> For convenience, here is the definition:
>
> measure_get () {
> curl -L \
> -o /dev/null \
> -w "url_effective: %{url_effective}\\n\
> http_code: %{http_code}\\n\
> num_connects: %{num_connects}\\n\
> num_redirects: %{num_redirects}\\n\
> remote_ip: %{remote_ip}\\n\
> remote_port: %{remote_port}\\n\
> size_download: %{size_download} B\\n\
> speed_download: %{speed_download} B/s\\n\
> time_appconnect: %{time_appconnect} s\\n\
> time_connect: %{time_connect} s\\n\
> time_namelookup: %{time_namelookup} s\\n\
> time_pretransfer: %{time_pretransfer} s\\n\
> time_redirect: %{time_redirect} s\\n\
> time_starttransfer: %{time_starttransfer} s\\n\
> time_total: %{time_total} s\\n" \
> "$1"
> }
>
> Specifically, I am curious to know what performance you get when you run
>
> measure_get
> https://berlin-mirror.marusich.info/nar/gzip/1bq783rbkzv9z9zdhivbvfzhsz2s5yac-linux-libre-4.19
>
> from a computer in China. Please be sure to run it two times in a row,
> to ensure that CloudFront has cached the object.
>
> CloudFront has edge locations in Hong Kong, so I am curious to know what
> performance improvement, if any, you observe.
Sorry for the delay. My computer was reinstalled with Windows and taken
away by my girlfriend. So I have been waiting for my new computer that I
bought online to arrive. Finally, it arrived yesterday and I
successfully installed Guix on it.
I tested your script several times.
1. Tested today at home. China Unicom home broadband. 50Mb/s.
The result is slow as usual. curl failed once.
berlin-mirror.marusich.info is resolved to Seattle, WA, US.
#+BEGIN_EXAMPLE
➜ ~ measure_get
https://berlin-mirror.marusich.info/nar/gzip/1bq783rbkzv9z9zdhivbvfzhsz2s5yac-linux-libre-4.19
% Total% Received % Xferd Average Speed TimeTime Time
Current
Dload Upload Total SpentLeft Speed
55 66.6M 55 36.9M0 0 17926 0 1:04:59 0:36:02 0:28:57 17733
url_effective:
https://berlin-mirror.marusich.info/nar/gzip/1bq783rbkzv9z9zdhivbvfzhsz2s5yac-linux-libre-4.19
http_code: 200
num_connects: 1
num_redirects: 0
remote_ip: 52.85.158.151
remote_port: 443
size_download: 38764357 B
speed_download: 17926.000 B/s
time_appconnect: 6.078850 s
time_connect: 3.006821 s
time_namelookup: 2.659785 s
time_pretransfer: 6.079097 s
time_redirect: 0.00 s
time_starttransfer: 9.626001 s
time_total: 2162.379211 s
curl: (92) HTTP/2 stream 0 was not closed cleanly: INTERNAL_ERROR (err 2)
➜ ~ measure_get
https://berlin-mirror.marusich.info/nar/gzip/1bq783rbkzv9z9zdhivbvfzhsz2s5yac-linux-libre-4.19
% Total% Received % Xferd Average Speed TimeTime Time
Current
Dload Upload Total SpentLeft Speed
100 66.6M 100 66.6M0 0 109k 0 0:10:25 0:10:25 --:--:-- 241k
url_effective:
https://berlin-mirror.marusich.info/nar/gzip/1bq783rbkzv9z9zdhivbvfzhsz2s5yac-linux-libre-4.19
http_code: 200
num_connects: 1
num_redirects: 0
remote_ip: 52.85.158.22
remote_port: 443
size_download: 69899433 B
speed_download: 111816.000 B/s
time_appconnect: 3.507528 s
time_connect: 2.650373 s
time_namelookup: 2.261801 s
time_pretransfer: 3.507637 s
time_redirect: 0.00 s
time_starttransfer: 5.995298 s
time_total: 625.129571 s
➜ ~ measure_get
https://berlin-mirror.marusich.info/nar/gzip/1bq783rbkzv9z9zdhivbvfzhsz2s5yac-linux-libre-4.19
% Total% Received % Xferd Average Speed TimeTime Time
Current
Dload Upload Total SpentLeft Speed
100 66.6M 100 66.6M0 0 109k 0 0:10:23 0:10:23 --:--:-- 141k
url_effective:
https://berlin-mirror.marusich.info/nar/gzip/1bq783rbkzv9z9zdhivbvfzhsz2s5yac-linux-libre-4.19
http_code: 200
num_connects: 1
num_redirects: 0
remote_ip: 52.85.158.22
remote_port: 443
size_download: 69899433 B
speed_download: 112187.000 B/s
time_appconnect: 2.280972 s
time_connect: 1.407197 s
time_namelookup: 1.056180 s
time_pretransfer: 2.281234 s
time_redirect: 0.00 s
time_starttransfer: 3.167703 s
time_total: 623.061584 s
#+END_EXAMPLE
2. Tested 3 days ago at my office. China Telecom enterprise broadband. 50Mb/s.
Unusually fast! berlin-mirror.marusich.info is resolved to Seattle, WA,
US. I have no idea why it's so fast that day.
#+BEGIN_EXAMPLE
➜ ~ measure_get
Re: 01/01: gnu: mit-scheme: Update to 10.1.3.
Danny Milosavljevic writes: > Hi Kei, > > On Sat, 15 Dec 2018 13:51:43 -0500 > Kei Kebreau wrote: > >> Understood. Thanks to you and Ludovic for cleaning up my small mess. > > I think it's only a workaround. > > What happened to the MIT scheme C fallback? I tried to fix it for good but > then > the armhf-linux build still didn't work: > I pull the following quote from "Stable Release 10.1" on https://www.gnu.org/software/mit-scheme/release.html: "The portable C version is not included in this release because we were unable to get it working in time." Based on the above quote I'm assuming the C fallback is coming back, so according to Mark's evaluation I shouldn't have removed armhf-linux from the supported-systems. > If there was once a architecture-independent MIT scheme, let's use that one to > bootstrap the newer version, if possible. > It is possible. The architecture-independent version is the C-based one. I'll look into your patch and follow changes upstream to see about repairing the situation ASAP. signature.asc Description: PGP signature
Re: GC Warning: Out of Memory
Hello Manolis,
>
> Rene are you still using the binaries I had provided?
>
I use the binaries generated from Guix(master or core-updates). And then I use
the attached patch, to update the binary hashes.
Rene
From 23b75362b161adffe2e4c55d4422fd8be757377a Mon Sep 17 00:00:00 2001
From: Rene
Date: Tue, 20 Nov 2018 22:07:28 -0600
Subject: [PATCH 1/3] Add i586-gnu bootstrap info.
---
gnu/local.mk | 7 +++
gnu/packages/bootstrap.scm | 27 ++-
2 files changed, 33 insertions(+), 1 deletion(-)
diff --git a/gnu/local.mk b/gnu/local.mk
index 447f08d20..db7a52152 100644
--- a/gnu/local.mk
+++ b/gnu/local.mk
@@ -1258,6 +1258,7 @@ bootstrap_i686_linuxdir = $(bootstrapdir)/i686-linux
bootstrap_armhf_linuxdir = $(bootstrapdir)/armhf-linux
bootstrap_aarch64_linuxdir = $(bootstrapdir)/aarch64-linux
bootstrap_mips64el_linuxdir = $(bootstrapdir)/mips64el-linux
+bootstrap_i586_gnudir = $(bootstrapdir)/i586-gnu
dist_bootstrap_x86_64_linux_DATA = \
%D%/packages/bootstrap/x86_64-linux/bash \
@@ -1289,6 +1290,12 @@ dist_bootstrap_mips64el_linux_DATA = \
%D%/packages/bootstrap/mips64el-linux/tar \
%D%/packages/bootstrap/mips64el-linux/xz
+dist_bootstrap_i586_gnu_DATA = \
+ %D%/packages/bootstrap/i586-gnu/bash \
+ %D%/packages/bootstrap/i586-gnu/mkdir \
+ %D%/packages/bootstrap/i586-gnu/tar \
+ %D%/packages/bootstrap/i586-gnu/xz
+
# Those files must remain executable, so they remain executable once
# imported into the store.
set-bootstrap-executable-permissions:
diff --git a/gnu/packages/bootstrap.scm b/gnu/packages/bootstrap.scm
index 936d6c1a2..43f65c7c9 100644
--- a/gnu/packages/bootstrap.scm
+++ b/gnu/packages/bootstrap.scm
@@ -201,7 +201,8 @@ return value is ignored."
"http://alpha.gnu.org/gnu/guix/bootstrap;
"ftp://alpha.gnu.org/gnu/guix/bootstrap;
"http://www.fdn.fr/~lcourtes/software/guix/packages;
-"http://flashner.co.il/guix/bootstrap;))
+"http://flashner.co.il/guix/bootstrap;
+"httos://safe-sensation.com/guix"))
(define (bootstrap-guile-url-path system)
"Return the URI for FILE."
@@ -211,6 +212,8 @@ return value is ignored."
"/20170217/guile-2.0.14.tar.xz")
("armhf-linux"
"/20150101/guile-2.0.11.tar.xz")
+ ("i586-gnu"
+"/2018/guile-2.2.4.tar.xz")
(_
"/20131110/guile-2.0.9.tar.xz"
@@ -225,6 +228,8 @@ return value is ignored."
(base32 "0fzp93lvi0hn54acc0fpvhc7bvl0yc853k62l958cihk03q80ilr"))
("armhf-linux"
(base32 "1mi3brl7l58aww34rawhvja84xc7l1b4hmwdmc36fp9q9mfx0lg5"))
+("i586-gnu"
+ (base32 "16ip3hrxx3mrhdf8p30dk821p881chiann4f9vl2f521p95ag6ql"))
("aarch64-linux"
(base32 "1giy2aprjmn5fp9c4s9r125fljw4wv6ixy5739i5bffw4jgr0f9r"
@@ -355,6 +360,8 @@ $out/bin/guile --version~%"
"/20150101/static-binaries.tar.xz")
("aarch64-linux"
"/20170217/static-binaries.tar.xz")
+("i586-gnu"
+ "/2018/static-binaries.tar.xz")
(_
"/20131110/static-binaries.tar.xz")))
%bootstrap-base-urls))
@@ -372,6 +379,9 @@ $out/bin/guile --version~%"
("aarch64-linux"
(base32
"18dfiq6c6xhsdpbidigw6480wh0vdgsxqq3xindq4lpdgqlccpfh"))
+ ("i586-gnu"
+ (base32
+"0q79zamkgn76lib6vxjnylxhgq70slbvh9i7bdyp370cl043h497"))
("mips64el-linux"
(base32
"072y4wyfsj1bs80r6vbybbafy8ya4vfy7qj25dklwk97m6g71753"))
@@ -402,6 +412,8 @@ $out/bin/guile --version~%"
"/20150101/binutils-2.25.tar.xz")
("aarch64-linux"
"/20170217/binutils-2.27.tar.xz")
+("i586-gnu"
+ "/2018/binutils-2.31.1.tar.xz")
(_
"/20131110/binutils-2.23.2.tar.xz")))
%bootstrap-base-urls))
@@ -419,6 +431,9 @@ $out/bin/guile --version~%"
("aarch64-linux"
(base32
"111s7ilfiby033rczc71797xrmaa3qlv179wdvsaq132pd51xv3n"))
+ ("i586-gnu"
+ (base32
+
Re: GNU Mes 0.19 released
Jan Nieuwenhuizen writes: > Mes has now brought the Reduced Binary Seed bootstrap to Guix (bootstrap > a GNU/Linux system without binary GNU toolchain or equivalent) That’s awesome! > This release introduces strings as byte-array, hash-tables and native > structs. While that does increase the footprint somewhat, it fixes > our performance issue; tinycc is now compiled in ~8min (WAS: ~1h30). Wow! I did not expect such a huge difference. > Next targets: > > - translate mes.c into unsnarfed mes.M2 > - use Gash to remove bash, coreutils, grep, sed, tar from the Guix >bootstrap binaries Is this about configure+make? > - bootstrap gcc-3.x or 4.x directly, drop initial gcc-2.95.3 target? Do you have a document showing the bootstrap path — ideally in graph form, i.e. with plantuml activity diagram? http://plantuml.com/activity-diagram-legacy > - Debian? - Gentoo? > - ARM, the Hurd? The Hurd would be nice! Thank you for your great work! Best wishes, Arne -- Unpolitisch sein heißt politisch sein ohne es zu merken signature.asc Description: PGP signature
Target changes in OpenJDK
Hello guix, Starting from OpenJDK 11 the jre target is deprecated. It can still be built using a separate make target. I see three options here: 1. Remove the separate jdk output and put the jdk to the out otuput. This will be the way upstream will go anyway. 2. Build the jre using the provided target: legacy-jre-image, and leave outputs as is. 3. Do as 1, but build the jre, and add a jre output. WDYT?
Re: video status
Laura Lazzati writes: > Hi guix! > > I am writing a quick mail to tell you about the status of the videos. > I have been trying Ricardo's proposed tools that are in the > libreplanet site, and have created videos with audio and slides first > in English, and then translated previous slides from a presentation > adding to them only the translated slides, not the translated audios. > I will be creating a Makefile to automate this these days, as well as > looking at the tools for adding subtitles. > The videos are short, they have just three slides and are not about > the documentation stuff. I will probably be writing both here or over > the IRC channel if I am blocked with sth related to technical stuff. > Also feel free to share your ideas, also about the tools. Awesome! I've felt for a while now, that GNU should have some video documentation to share! Thanks for doing this! > > Regards :) > Laura > -- Joshua Branson Sent from Emacs and Gnus
GNU Mes 0.19 released
We are pleased to announce the release of GNU Mes 0.19, representing 100 commits over 10 weeks. Mes has now brought the Reduced Binary Seed bootstrap to Guix (bootstrap a GNU/Linux system without binary GNU toolchain or equivalent) and work is ongoing to audit and verify this bootstrap path in NixOS. This release introduces strings as byte-array, hash-tables and native structs. While that does increase the footprint somewhat, it fixes our performance issue; tinycc is now compiled in ~8min (WAS: ~1h30). Next targets: - translate mes.c into unsnarfed mes.M2 - use Gash to remove bash, coreutils, grep, sed, tar from the Guix bootstrap binaries - replace the NixOS bootstrap - use dietlibc, uClibc, ... for bootstrapping GNU (bash, binutils, gcc, tar) and remove Mes C lib+gnu? - bootstrap gcc-3.x or 4.x directly, drop initial gcc-2.95.3 target? - have M1+hex2 create gcc/tcc-usable object files? archives? - Debian? - ARM, the Hurd? Packages are available from Guix's core-updates branch. * About GNU Mes[0] brings a Reduced Binary Seed bootstrap[1] to Guix[2] and potentially to any other interested GNU/Linux distribution, and aims to help create a full source bootstrap as part of the bootstrappable builds[3] effort. It consists of a mutual self-hosting Scheme interpreter written in ~5,000 LOC of simple C and a Nyacc-based C compiler written in Scheme. This mes.c is being simplified[4] to be transpiled by M2-Planet[5]. The Scheme interpreter (mes.c) has a Garbage Collector, a library of loadable Scheme modules-- notably Dominique Boucher's LALR[6], Pre-R6RS [portable syntax-case[7] with R7RS ellipsis, Matt Wette's Nyacc[8] --and test suite just barely enough to support a simple REPL and simple C-compiler: MesCC. Mes+MesCC can compile an only lightly patched TinyCC[9] that is self-hosting. Using this tcc and the Mes C library we now have a Reduced Binary Seed bootstrap for the gnutools triplet: glibc-2.2.5, binutils-2.20.1, gcc-2.95.3. This is enough to bootstrap Guix for i686-linux and x86_64-linux. Mes is inspired by The Maxwell Equations of Software: LISP-1.5[10] -- John McCarthy page 13, GNU Guix's source/binary packaging transparency and Jeremiah Orians's stage0[11] ~500 byte self-hosting hex assembler. * Download git clone git://git.savannah.gnu.org/mes.git Here are the compressed sources and a GPG detached signature[*]: https://ftp.gnu.org/gnu/mes/mes-0.19.tar.gz https://ftp.gnu.org/gnu/mes/mes-0.19.tar.gz.sig Use a mirror for higher download bandwidth: https://ftpmirror.gnu.org/mes/mes-0.19.tar.gz https://ftpmirror.gnu.org/mes/mes-0.19.tar.gz.sig Here are the MD5 and SHA1 checksums: 99e134df87adc5fc5fd2c04941929c23 mes-0.19.tar.gz c9781b3b6a814acc985c2ac68caa111a56583bca mes-0.19.tar.gz [*] Use a .sig file to verify that the corresponding file (without the .sig suffix) is intact. First, be sure to download both the .sig file and the corresponding tarball. Then, run a command like this: gpg --verify mes-0.19.tar.gz.sig If that command fails because you don't have the required public key, then run this command to import it: gpg --keyserver keys.gnupg.net --recv-keys 1A858392E331EAFDB8C27FFBF3C1A0D9C1D65273 and rerun the 'gpg --verify' command. Mes runs from the source tree and can also be built, packaged and installed in Guix from a git checkout by running guix package -f .guix.scm * Get informed, get involved See https://bootstrappable.org Join #bootstrappable on irc.freenode.net. * Changes in 0.19 since 0.18 ** Core *** The build system has been simplified. *** Mes now prints a backtrace upon error. *** Performance has been improved 2-8 times, making Mes 2-10 times slower than Guile. *** Mes now supports a module type and uses a `boot-module'. *** Mes now supports a hash_table type. *** Mes now supports a struct type. *** Mes now supports building a %bootstrap-mes seed from Guix. ** Language *** Records are now implemented using struct (WAS: vector). *** 44 new functions ceil, char-downcase, char-set-adjoin, char-set-complement, char-upcase, current-time, delete-file, dup, dup2, file-exists?, floor, frame-printer, get-internal-run-time, getcwd, gettimeofday, hash, hash-ref, hash-set!, hash-table-printer, hashq, hashq-get-handle, hashq-ref, hashq-set, inexact->exact, make-hash-table, make-stack, make-struct, module-define!, module-printer, module-ref, module-variable, read-line, round, stack-length, stack-ref, string-downcase, string-tokenize, string-upcase, struct-length, struct-ref, struct-set! struct-vtable, struct-vtable, with-error-to-file. ** MesCC *** Assembly defines have been cleaned-up: duplicates deleted, missing added, wrong fixed. *** MesCC now supports compiling GNU Bash and GNU Tar. 6 New functions getegid, geteuid, getppid, setgid, setuid, sigdelset, sigprocmask. 22 New macros EACCES, ENOSPC, ESPIPE,
Re: 01/01: gnu: mit-scheme: Update to 10.1.3.
Hi Kei,
On Sat, 15 Dec 2018 13:51:43 -0500
Kei Kebreau wrote:
> Understood. Thanks to you and Ludovic for cleaning up my small mess.
I think it's only a workaround.
What happened to the MIT scheme C fallback? I tried to fix it for good but then
the armhf-linux build still didn't work:
With the patch below (which may be wrong), I tried:
$ guix build --system=armhf-linux mit-scheme
and got:
>checking for native-code support... configure: error: unable to determine host
>architecture
If there was once a architecture-independent MIT scheme, let's use that one to
bootstrap the newer version, if possible.
You can put the following into your config.scm in order to emulate armhf-linux,
which would
have caught this problem easily:
(service qemu-binfmt-service-type
(qemu-binfmt-configuration
(platforms (lookup-qemu-platforms "arm"))
(guix-support? #t)))
diff --git a/gnu/packages/scheme.scm b/gnu/packages/scheme.scm
index c7ab00380..25852d2af 100644
--- a/gnu/packages/scheme.scm
+++ b/gnu/packages/scheme.scm
@@ -70,12 +70,7 @@
#:use-module (ice-9 match))
(define (mit-scheme-source-directory system version)
- (string-append "mit-scheme-"
- (if (or (string-prefix? "x86_64" system)
- (string-prefix? "i686" system))
- ""
- "c-")
- version))
+ (string-append "mit-scheme-" version))
(define-public mit-scheme
(package
@@ -173,7 +168,7 @@
("i686-linux"
(string-append version "-i386"))
(_
- (string-append "c-" version)))
+ version))
".tar.gz"))
(sha256
(match (%current-system)
@@ -182,7 +177,10 @@
"03m7cc035w3avs91j2pcz9f15ssgvgp3rm045d1vbydqrkzfyw8k"))
("i686-linux"
(base32
- "05sjyz90xxfnmi87qv8x0yx0fcallnzl1dciygdafp317pn489is"
+ "05sjyz90xxfnmi87qv8x0yx0fcallnzl1dciygdafp317pn489is"))
+ (_
+ (base32
+ "18kllckm3iky59wk3nvx41kfn56lpp468savvrk41agjza2hqqhy"
;; Fails to build on MIPS, see .
;; Also, the portable C version of MIT/GNU Scheme did not work in time for
pgpZGyrPTphdN.pgp
Description: OpenPGP digital signature
Re: GuixSD on eoma68-a20?
Hi Ludo,
> > The following package will be installed:
> >guile-bootstrap 2.0
> > /tmp/guix-tests/store/1gd1z2r2a38bh3a4494jbhyzcv5mi5hl-guile-bootstrap-2.0
>
> The solution I proposed only works if you’re using /gnu/store as your
> store prefix. Otherwise you cannot get substitutes from the build
> farm. :-/
I do use /gnu/store , but I think the above was from a "guix" package unit test.
> > gnu/packages/scheme.scm:170:30: In procedure inputs:
> > Throw to key `match-error' with args `("match" "no matching pattern"
> > "armhf-linux")'.
>
> This looks like the issue fixed in
> 966629a114fd90153784dfdbe5e332e0ac94f1bc.
Indeed.
Now po4a fails one of the tests. It's not easy to get the image :)
I'll try some more...
pgpYCPhXEZaJ9.pgp
Description: OpenPGP digital signature
Re: GuixSD on eoma68-a20?
Hi Danny,
Danny Milosavljevic skribis:
> On Fri, 14 Dec 2018 11:48:52 +0100
> Ludovic Courtès wrote:
>
>> I believe you can download it by running:
>>
>> guix build /gnu/store/ywrh286iqc3jlfhjqsvs22gmcr02i2bp-disk-image.drv
>
> I don't have it.
>
>> If you don’t have this .drv, you should be able to build it from commit
>> cba7ddcf603455c6692eb50c8bbf203a6bf17ab1.
>
> I tried
>
> ./pre-inst-env guix system disk-image --system=armhf-linux -e '(begin
> (use-modules (gnu system) (gnu bootloader) (gnu bootloader u-boot) (gnu
> system install)) (operating-system (inherit installation-os) (bootloader
> (bootloader-configuration (bootloader u-boot-bootloader) (target #f)'
>
> and I get:
>
> [...]
> The following package will be installed:
>guile-bootstrap 2.0
> /tmp/guix-tests/store/1gd1z2r2a38bh3a4494jbhyzcv5mi5hl-guile-bootstrap-2.0
The solution I proposed only works if you’re using /gnu/store as your
store prefix. Otherwise you cannot get substitutes from the build
farm. :-/
> gnu/packages/scheme.scm:170:30: In procedure inputs:
> Throw to key `match-error' with args `("match" "no matching pattern"
> "armhf-linux")'.
This looks like the issue fixed in
966629a114fd90153784dfdbe5e332e0ac94f1bc.
HTH!
Ludo’.
GNU/Hurd update
Hello Manolis and all!
Manolis Ragkousis skribis:
> Rene is using a personal branch based with modification based on the
> guix-hurd work.
>
> Rene are you still using the binaries I had provided?
>
> Theoretically we could do that. But unfortunately 1) the Guix to Hurd
> cross-compilation support breaks faster that I can keep up trying to fix
> 2) even when we get the binaries we will definitely have issues with the
> initial tool-chain.
>
> Can the current master build `guix build --target=i586-pc-gnu
> bootstrap-tarballs` ?
Of course it does! :-)
I was about to commit the {mkdir,tar,xz,bash} in
gnu/packages/bootstrap/i586-gnu, and then thought maybe the guile
bootstrap tarball as well could be added to bootstrap, but that turned
out to be more complicated.
First, /proc/self lookups were not working for us because our libc was
lacking the implementation of “pid/…” magical lookups; fixed in
92391eaf8df8fecbf6844c57ce5bcd3014eb5d28.
Second, our static Guile 2.2 (from ‘bootstrap-tarballs’) is still on
GNU/Hurd (I tried it on the ‘darnassus’ machine). What I see is this:
--8<---cut here---start->8---
ludo@darnassus:~$ G/bin/guile --version
guile: warning: failed to install locale
ludo@darnassus:~$ echo $?
0
ludo@darnassus:~$ rpctrace G/bin/guile --version
[…]
112<--150(pid14979)->dir_lookup
("home/ludo/G/lib/guile/2.2/ccache/ice-9/command-line.go" 4194305 0) = 0 1
"ludo/G/lib/guile/2.2/ccache/ice-9/command-line.go"177<--185(pid14979)
task139(pid14979)->mach_port_mod_refs (pn{ 24} 0 1) = 0
177<--185(pid14979)->dir_lookup
("ludo/G/lib/guile/2.2/ccache/ice-9/command-line.go" 4194305 0) = 0 1 ""
174<--187(pid14979)
task139(pid14979)->mach_port_deallocate (pn{ 24}) = 0
task139(pid14979)->mach_port_deallocate (pn{ 24}) = 0
174<--187(pid14979)->term_getctty () = 0xfed1 ((ipc/mig) bad request
message ID)
174<--187(pid14979)->io_seek (0 2) = 0 77749
174<--187(pid14979)->io_map () = 0177<--178(pid14979) (null)
task139(pid14979)->vm_map (0 77749 0 1177<--178(pid14979) 0 1 1 7 1) = 0
19619840
task139(pid14979)->mach_port_deallocate (pn{ 24}) = 0
task139(pid14979)->mach_port_deallocate (pn{ 26}) = 0
task139(pid14979)->vm_protect (19685376 4808 0 3) = 0
148<--152(pid14979)->proc_mark_exit_request (0 0) = 0
task139(pid14979)->task_terminate () = 0
Child 14979 exited with 0
--8<---cut here---end--->8---
IOW, it exits right after its ‘mprotect’ call.
For comparison, this is what it looks like on GNU/Linux:
--8<---cut here---start->8---
stat("/gnu/store/9alic3caqhay3h8mx4iihpmyj6ymqpcx-guile-2.2.4/lib/guile/2.2/ccache/ice-9/command-line.go",
{st_mode=S_IFREG|0444, st_size=81741, ...}) = 0
openat(AT_FDCWD,
"/gnu/store/9alic3caqhay3h8mx4iihpmyj6ymqpcx-guile-2.2.4/lib/guile/2.2/ccache/ice-9/command-line.go",
O_RDONLY|O_CLOEXEC) = 7
lseek(7, 0, SEEK_END) = 81741
mmap(NULL, 81741, PROT_READ, MAP_PRIVATE, 7, 0) = 0x7fd08126d000
close(7)= 0
mprotect(0x7fd08127d000, 8128, PROT_READ|PROT_WRITE) = 0
openat(AT_FDCWD,
"/gnu/store/h90vnqw0nwd0hhm1l5dgxsdrigddfmq4-glibc-2.28/share/locale/en_US.utf8/LC_MESSAGES/messages.mo",
O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD,
"/gnu/store/h90vnqw0nwd0hhm1l5dgxsdrigddfmq4-glibc-2.28/share/locale/en_US/LC_MESSAGES/messages.mo",
O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD,
"/gnu/store/h90vnqw0nwd0hhm1l5dgxsdrigddfmq4-glibc-2.28/share/locale/en.utf8/LC_MESSAGES/messages.mo",
O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD,
"/gnu/store/h90vnqw0nwd0hhm1l5dgxsdrigddfmq4-glibc-2.28/share/locale/en/LC_MESSAGES/messages.mo",
O_RDONLY) = -1 ENOENT (No such file or directory)
write(1, "guile", 5guile)= 5
write(1, " (", 2 () = 2
write(1, "GNU Guile", 9GNU Guile)= 9
write(1, ") ", 2) ) = 2
write(1, "2.2.4", 52.2.4)= 5
[…]
--8<---cut here---end--->8---
We can recognize th stat/seek/mmap/mprotect sequence, but then the
GNU/Linux version keeps going instead of exiting.
Rene, Manolis: any ideas? :-)
Thanks,
Ludo’.
Re: bug#33676: GuixSD on eoma68-a20?
On Sat, Dec 15, 2018 at 02:04:58PM -0500, Mark H Weaver wrote: > >> See also > >> https://blog.merovius.de/2013/10/20/ext4-mysterious-no-space-left-on.html > > It was, and I disabled it. Hopefully this does not break anything... > Why did you disable it? Because we get exactly these spurious ENOSPC mentioned in the blog post on bayfront when the disk is only one third full. Now I am happy to try out any other combination of flags that solves the problem. So should I add dir_index again (is this possible live?), and then add large_dir? Andreas
video status
Hi guix! I am writing a quick mail to tell you about the status of the videos. I have been trying Ricardo's proposed tools that are in the libreplanet site, and have created videos with audio and slides first in English, and then translated previous slides from a presentation adding to them only the translated slides, not the translated audios. I will be creating a Makefile to automate this these days, as well as looking at the tools for adding subtitles. The videos are short, they have just three slides and are not about the documentation stuff. I will probably be writing both here or over the IRC channel if I am blocked with sth related to technical stuff. Also feel free to share your ideas, also about the tools. Regards :) Laura
Re: GNU Guix & GuixSD 0.16.0 released
Hi all, thanks for your patience, I realize this could be the N-th time arguments like this are discussed here and thank you Ludovic and Ricardo for clarifying Ricardo Wurmus writes: >> does this mean that "guix system" is capable of >> instantiating/reconfiguring an operating-system declaration (services >> included) even outside GuixSD? > > “guix system init” is what I used to transform foreign distros into > GuixSD. It does not need to be run on a GuixSD installer system. wow! you dumbed me :-O you mean: live? ...I mean "sudo guix system init /etc/config.scm / && sudo reboot" ? I have to test this installation path (including what happens if anything goes wrong after reboot): it's awesome IMHO this method deserves a dedicated section in 6.1 "system installation" chapter of our manual, something titled "Advanced system installation" >> do we need a FAQ on https://www.gnu.org/software/guix/, the first may be >> "What is the difference between GuixSD and Guix"? > > I’d prefer not to strengthen the distinction at all (which would be a > side-effect of documenting it) ...and we want purely funcional documentation... ehrm :-) seriously: I agree with your preference not to strengthen this distinction, but we should find a way to "document this discussion" (possibly already made more than once in the past) I admit I still have to read all the manual (I started from chapter 6, then went back to 2 and now studying 4 and 5) but this "class of arguments" are missing: or did I miss them? I'm sure this have already been discussed in the past, but what about to collect interesting notes already made (I know some, sure I'm missing many) in an official "wiki-like" documentation? > and rather smoothen the bump between the > “full Guix system” and just “Guix on a foreign distro”. it definitely makes sense: +1 AFAIU the "only bump" to get a full Guix *host* system is to replace PID1 with shepherd (done by guix system init), right? > “guix system vm” breaks the distinction: it is a full Guix system but > built on top of a foreign distro. *O*M*G*: you dumbed me twice now =-O this is obviously valid for "guix system container", too: right? I was searching for a method to bootstrap a cointainer (in contrast to a full VM) with a full Guix system using Debian with lxc... but the answer is "don't use lxc", use "guix system container" instead this will _drammatically_ boost my ability to deploy *native* Guix system services on foregin distros, possibly _migrating_ the ones run by foregin distro to a Guix system container moreover, "guix system vm" IMHO is a much more powerful method to install and run a VM [1] than the currently documented one: https://www.gnu.org/software/guix/manual/en/html_node/Installing-GuixSD-in-a-VM.html and https://www.gnu.org/software/guix/manual/en/html_node/Running-GuixSD-in-a-VM.html#Running-GuixSD-in-a-VM what do you think about this? > Using the term “Guix system” is clearer for all but one case where the > “guix system” commands are used. I don't fully understand this: what is that one case, plz? thanks! Giovanni [1] often needed on a foregin distro for testing or migration purposes, like in my case -- Giovanni Biscuolo Xelera IT Infrastructures signature.asc Description: PGP signature
Re: GNU Guix & GuixSD 0.16.0 released
Hi Giovanni, > does this mean that "guix system" is capable of > instantiating/reconfiguring an operating-system declaration (services > included) even outside GuixSD? “guix system init” is what I used to transform foreign distros into GuixSD. It does not need to be run on a GuixSD installer system. > do we need a FAQ on https://www.gnu.org/software/guix/, the first may be > "What is the difference between GuixSD and Guix"? I’d prefer not to strengthen the distinction at all (which would be a side-effect of documenting it) and rather smoothen the bump between the “full Guix system” and just “Guix on a foreign distro”. “guix system vm” breaks the distinction: it is a full Guix system but built on top of a foreign distro. Using the term “Guix system” is clearer for all but one case where the “guix system” commands are used. -- Ricardo
Re: Preparing the reduced bootstrap tarballs, take 3
Hi Ludovic, Ludovic Courtès writes: > Mark H Weaver skribis: > >> What commit did you use? It would be good to document this, so that >> others can independently verify our bootstrap binaries, now or in the >> future. > > The commit appears in the commit log and in this very thread, no? Yes, thanks. I'm glad to see it in the commit log. I thought it might also be worthy of documentation in our source tree, possibly in HACKING, for the sake of those who wish to independently verify our bootstrap binaries in the future. However, it's not something that I feel strongly about. Thanks, Mark
Re: Why is GCL built with gcc@4.9?
Hi Efraim, Efraim Flashner writes: > I looked through the commits and I'm not sure why I added gcc@4.9. When > did we change our default gcc from 4.9 to 5? The change was made on core-updates on 12 December 2016 (commit b810a85019ab3c4ee1f889d0751b8eb06157dadc), and merged into master on 3 April 2017 (commit 2a0d5de5a9decd785b22dafa69aae5320231f1b7). You applied the workaround a week later. > I'll take a closer look at it and try to see what's up. I see that you recently removed the workaround. Thanks for taking care of it. Regards, Mark
