Re: Hi, I am R Veera Kumar - Current Outreachy selected Applicant
Hello, Veera ezt írta (időpont: 2020. márc. 8., Vas 8:41): > On Sat, Mar 07, 2020 at 09:31:32PM +0100, Gábor Boskovits wrote: > > Hello Veera, > > > > Veera ezt írta (időpont: 2020. márc. 7., Szo 16:05): > > > > > Hi, > > > > > > I am R Veera Kumar from India. I have been selected as Outreachy > applicant > > > for May 2020 round. > > > > > Nice to see you around. > > > > Thanks! > > > > > > > > > I have heard about Guix from news and have checked about it a little > > > before. > > > I do not know Scheme/Guile Language. > > > > > This is not a problem. I believe it can be picked up easily. This won't > be > > the biggest burden in the project. > > > > Oh well. > > > > > > > How do I get started? > > > What contributions can I make? > > > > > > > To get started you should install guix. For this project it might make > > sense to install guix system also. You should also set up a guix > > development environment, by checking out the source code, and building > it. > > > > I am installing GuixSD. > How did the install go? Could you do it? Please feel free to reach out to me should you have any questions. > > > The usual first time contribution we recommend is to package an R package > > from cran that has all its dependencies in guix using the importer. > > > > You can also check out http://issues.guix.gnu.org/easy and work on some > > easy bugs. > > > > Yes. I checked that. > > > Thanks for your interest. I hope that I could give you useful > information. > > > > Best regards, > > g_bor > > > > Thanks for the welcome! > > Regards, > Veera > Best regards, G_bor >
Re: About guix mirror build script
Dear, On Tue, 10 Mar 2020 at 03:48, tumashu wrote: > In China , guix substitute download seem to be to slow, > nearly unuseable. About which kind of substitutes are you talking? 1. from where Guix pulls? (guix pull) 2. from where Guix fetches the binaries? (guix install) About 1. we had a discussion [1] on December about mirroring the official Git repo on Savannah. But AFAIK, nothing relevant has be done in this area. Feel free to propose a plan. :-) About 2. currently the binaries are mainly served by ci.guix.gnu.org located in Berlin. And an attempt to use CDN had been done a couple of month ago. You could be interested by this thread [2] and as you reported [3] the CDN experience was improving the situation in China. Well, the best is perhaps to time the issue, see this message [4]. [1] https://lists.gnu.org/archive/html/guix-devel/2019-12/msg00148.html [2] https://lists.gnu.org/archive/html/guix-devel/2019-03/msg00135.html [3] https://lists.gnu.org/archive/html/guix-devel/2019-03/msg00222.html [4] https://lists.gnu.org/archive/html/guix-devel/2018-12/msg00192.html On the long term, a patch [5] using IPFS needs some love (review, tests, etc.). [5] https://issues.guix.info/issue/33899 > this week, I have found that NIX channels has been built China mirror > successful with the help of > 4 files: > > 1. https://github.com/tuna/tunasync-scripts/blob/master/nix.py > 2. https://github.com/tuna/tunasync-scripts/blob/master/nix-channels.py > 3. https://github.com/tuna/tunasync-scripts/blob/master/nixos-images.py > 4. > https://github.com/tuna/tunasync-scripts/blob/master/dockerfiles/nix-channels/Dockerfile > > guix is very similar nix, so I want to know how to port 4 files to work with > guix? > is it possible add similar tools to guix? Well, I have not dove into all these Python scripts to know exactly what they are doing. And I do not know what are the storage resources one needs to mirror ci.guix.gnu.org. But yes, if you have the resources (storage) to mirror the binaries susbtitute, you can try to adapt these scripts by replacing the URLs. All the best, simon
Re: 08/33: gnu: make: Revert to 4.1 for the Hurd.
Hello janneke! I’m commenting as I see messages come by, hope that’s fine. :-) guix-comm...@gnu.org skribis: > commit f7804e0f00741a65e7538fe7f3f0cf9844c2165c > Author: Jan Nieuwenhuizen > AuthorDate: Wed Feb 26 20:22:18 2020 -0500 > > gnu: make: Revert to 4.1 for the Hurd. > > * gnu/packages/base.scm (gnu-make-4.1): New variable. > * gnu/packages/commencement.scm (gnu-make-boot0): Use it for the Hurd. How much effort would it be to patch current Make for the Hurd? It would be ideal if we could apply the patch unconditionally and have a single Make variant. > (define gnu-make-boot0 >(package > (inherit gnu-make) > -(source (bootstrap-origin (package-source gnu-make))) > +(version (if (hurd-system?) "4.1" > + (package-version gnu-make))) > +(source (if (hurd-system?) > +(bootstrap-origin (package-source gnu-make-4.1)) > +(bootstrap-origin (package-source gnu-make This won’t work as expected because ‘source’ is no thunked, and thus (hurd-system?) is evaluated at the top level, when the module is loaded. (IOW, if you do “-s i586-gnu” from GNU/Linux, it’ll go through the wrong arm of the ‘if’.) Ludo’.
Re: 05/33: gnu: hurd: Fix hurd-target?.
guix-comm...@gnu.org skribis: > commit cd5f9ba3b1130d8f54b1ef33106f25f29732e007 > Author: Jan Nieuwenhuizen > AuthorDate: Wed Mar 4 11:49:46 2020 -0500 > > gnu: hurd: Fix hurd-target?. > > * gnu/packages/hurd.scm (hurd-target?): Bugfix; the arguments to > string-suffix? to test (%current-system) were transposed, always resulting > in #f. Use hurd-triplet?. Would be nice to squash with the previous one. :-)
Re: `guix build hello' now succeeds on the Hurd
Ludovic Courtès writes: >> The situation on the Hurd starts to look pretty good >> >> janneke@debian:~/src/guix$ ./pre-inst-env guix build hello --no-offload >> /gnu/store/a2sylb94rm1b6qxcp5mqvgiyx9szipz7-hello-2.10 >> janneke@debian:~/src/guix$ >> /gnu/store/a2sylb94rm1b6qxcp5mqvgiyx9szipz7-hello-2.10/bin/hello >> Hello, world! >> >> \o/ > > Woohoo! Congrats! > > How do you run guix-daemon? (In the future it’d be great to perhaps > implement Linux namespaces on the Hurd in libc.) I have slightly cleaned-up a patch by Manolis so that I can run sudo ./pre-inst-env guix-daemon --disable-chroot --build-users-group=guixbuild & This and other useful recipes I have noted in my scratchbook on the Hurd https://gitlab.com/janneke/guix/-/blob/wip-hurd-system/THE-HURD I briefly looked at more work-in-progress daemon patches by Manolis, but stopped when I found that it needs [t]his "new" libhurdutils library... @Manolis? > Merging what you have—the earlier the better. :-) >> Shall I push this to savannah as `wip-hurd' (possibly save wip-hurd-> >> `wip-hurd-old?); > > Yup, sounds like a plan. Great, thanks, done; follow-up here! https://debbugs.gnu.org/cgi/bugreport.cgi?bug=40006 https://issues.guix.info/issue/40006 >> I could also rewrite wip-hurd-bootstrap? > > Dunno! > > To me, the difficult bit with porting and bootstrapping work is making > sure that bootstrap.scm/commencement.scm/base.scm/cross-base.scm remain > maintainable. All this complexity adds up so we must spend time trying > to, for instance, minimize variation across platforms/OSes. Every line > of code and above all every conditional avoided in these files is a win > in the not-so-long term. That’d be my guideline as we merge it. :-) > > Anyhow, thumbs up! I’m looking forward to merging it and having it > built on CI (we could offload to a Debian VM!)! Yes, that would be awesome! janneke -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
Re: 11/33: gnu: glibc: Add and update patches for the Hurd.
Hi, guix-comm...@gnu.org skribis: > commit 32d3fa5309532b8bcf7f7be15ffabfa99c6ecfaf > Author: Jan Nieuwenhuizen > AuthorDate: Sun Mar 1 16:37:37 2020 +0100 > > gnu: glibc: Add and update patches for the Hurd. > > * gnu/packages/patches/glibc-hurd-magic-pid.patch: Remove unused file. > * gnu/packages/patches/glibc-hurd-clock_t_centiseconds.patch: New file. > * gnu/packages/patches/glibc-hurd-clock_gettime_monotonic.patch: New file. > * gnu/local.mk (dist_patch_DATA): Update them. > * gnu/packages/base.scm (glibc): Use two new patches. [...] > -(patches (search-patches "glibc-ldd-x86_64.patch" > +(patches `(,@(search-patches "glibc-ldd-x86_64.patch" ^ Superfluous. :-) > + > "glibc-hurd-clock_t_centiseconds.patch" > + > "glibc-hurd-clock_gettime_monotonic.patch") Nice patches! Did you submit them upstream? They are likely to be applied quite quickly nowadays, so they could make it in glibc 2.32. (It’s fine to carry them in the meantime, of course.) Ludo’.
Re: 33/33: daemon: Workaround issues for the Hurd.
guix-comm...@gnu.org skribis:
> commit c32b64950972a459af7192abd7a8bc9619c013e9
> Author: Manolis Ragkousis
> AuthorDate: Wed Dec 28 02:49:22 2016 +0200
>
> daemon: Workaround issues for the Hurd.
>
> This allows for native builds on the Hurd, doing
>
> sudo ./pre-inst-env guix-daemon --disable-chroot
> --build-users-group=guixbuild &
> ./pre-inst-env guix build hello
>
> * nix/libstore/build.cc (DerivationGoal::startBuilder)[__GNU__]: Allow
> non-chrooted build.
> * nix/libutil/util.cc (killUser)[__GNU__]: Avoid wait failure.
[...]
> +++ b/nix/libstore/build.cc
> @@ -1824,7 +1824,7 @@ void DerivationGoal::startBuilder()
> }
>
> if (useChroot) {
> -#if CHROOT_ENABLED
> +#if CHROOT_ENABLED || __GNU__
Can we instead change the #define CHROOT_ENABLED such that
CHROOT_ENABLED is always true when __GNU__? Also with a comment stating
that GNU supports chroot(2) without being root.
> +++ b/nix/libutil/util.cc
> @@ -872,9 +872,11 @@ void killUser(uid_t uid)
> _exit(0);
> });
>
> +#if !__GNU__
> int status = pid.wait(true);
> if (status != 0)
> throw Error(format("cannot kill processes for uid `%1%': %2%") % uid
> % statusToString(status));
> +#endif
Do you know what the rationale was? It looks like it could leave
zombies behind us.
Ludo’.
Re: 15/33: gnu: coreutils: Remove libcap dependency for the Hurd.
guix-comm...@gnu.org skribis: > commit ae159bde64917511d345cd2e1dd1feabe5f73b72 > Author: Jan Nieuwenhuizen > AuthorDate: Sat Mar 7 03:53:38 2020 -0500 > > gnu: coreutils: Remove libcap dependency for the Hurd. > > * gnu/packages/base.scm (coreutils)[inputs]: Remove libcap for the Hurd. > --- > gnu/packages/base.scm | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/gnu/packages/base.scm b/gnu/packages/base.scm > index 9f1477b..4b347a7 100644 > --- a/gnu/packages/base.scm > +++ b/gnu/packages/base.scm > @@ -304,7 +304,9 @@ used to apply commands with arbitrarily long arguments.") > > ;; Drop the dependency on libcap when cross-compiling since it's > ;; not quite cross-compilable. > - ,@(if (%current-target-system) > + ;; Also, libcap is not available on the Hurd. > + ,@(if (or (%current-target-system) > + (hurd-target?)) Perhaps we’d also need something based on ‘supported-platforms’ here. (Not a blocker, though.) Ludo’.
Re: 27/33: gnu: commencement: glibc-intermediate: Build fixes for the Hurd.
guix-comm...@gnu.org skribis:
> ;; Tell 'libpthread' where to find 'libihash' on Hurd
> systems.
> - ,@(if (hurd-triplet? (%current-system))
> - `((substitute* "libpthread/Makefile"
> - (("LDLIBS-pthread.so =.*")
> - (string-append "LDLIBS-pthread.so = "
> - (assoc-ref %build-inputs
> "kernel-headers")
> - "/lib/libihash.a\n"
> + ,@(if (hurd-system?)
> + `(map
> + (lambda (f)
> +(substitute* f
> + (("LDLIBS-pthread.so =.*")
> + (string-append "LDLIBS-pthread.so = "
> + (assoc-ref %build-inputs
> "kernel-headers")
> + "/lib/libihash.a\n")))
> +'("sysdeps/mach/Makefile"
> + "sysdeps/mach/hurd/Makefile:")))
‘substitute*’ accepts a list of files, so you can write it like this:
(substitute* '("sysdeps/mach/hurd/Makefile" "sysdeps/mach/Makefile")
…)
Ludo’.
Re: 23/33: gnu: commencement: gcc-boot0: Build fix for the Hurd.
guix-comm...@gnu.org skribis: > commit 7a57ca758c590742b63100944f07fddb7290f797 > Author: Jan Nieuwenhuizen > AuthorDate: Sun Mar 1 13:45:42 2020 +0100 > > gnu: commencement: gcc-boot0: Build fix for the Hurd. > > Fixes: > g++ -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -fno-exceptions > -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing > -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual > -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings > -DHAVE_CONFIG_H -DGENERATOR_FILE -fno-PIE -static-libstdc++ -static-libgcc > -Wl,-rpath=/gnu/store/vp2id82a597p119b3wyhhkhd467wvn78-glibc-bootstrap-0/lib > -Wl,-dynamic-linker -Wl,/gnu/store/vp2id82a597p119b3w [...] > build/genmddeps.o build/read-md.o build/errors.o > ../build-i586-unknown-gnu/libiberty/libiberty.a > > /gnu/store/jk3kx5jwjs9m60svzk6sz79bf0w33l91-binutils-cross-boot0-2.34/bin/ld: > build/read-md.o: in function `md_reader::~md_reader()': > > /tmp/guix-build-gcc-cross-boot0-7.5.0.drv-0/build/gcc/../../gcc-7.5.0/gcc/read-md.c:1049: > undefined reference to `operator delete(void*, unsigned int)' > > This raises the question: Should libstdc++-boot0 (v4.9) be sufficient to > build > gcc-boot0 (v7.5.0)? Hmm? :-) > * gnu/packages/commencement.scm (gcc-boot0): Add static library path. > `(,(string-append "LDFLAGS=" > + (if ,(hurd-system?) > + (string-append > + "-L" (assoc-ref %build-inputs "gcc") > "/lib ") > + "") Could you add a comment saying that this is to allow the ‘delete’ operator to be found? Weird. That’s it, thanks for the great work! Ludo’.
Re: 08/33: gnu: make: Revert to 4.1 for the Hurd.
Ludovic Courtès writes: Hello Ludo, > I’m commenting as I see messages come by, hope that’s fine. :-) Sure, that's great! > guix-comm...@gnu.org skribis: > >> commit f7804e0f00741a65e7538fe7f3f0cf9844c2165c >> Author: Jan Nieuwenhuizen >> AuthorDate: Wed Feb 26 20:22:18 2020 -0500 >> >> gnu: make: Revert to 4.1 for the Hurd. >> >> * gnu/packages/base.scm (gnu-make-4.1): New variable. >> * gnu/packages/commencement.scm (gnu-make-boot0): Use it for the Hurd. > > How much effort would it be to patch current Make for the Hurd? It > would be ideal if we could apply the patch unconditionally and have a > single Make variant. I agree, I don't know :-) v4.3 compiles fine but apart from --help and --version it hangs when invoked. I hoped it would be fixed after applying the clock patches, but those only worked for Python. We could either try to debug it or try some/all of Debian's glibc patches. If it's already fixed by patching glibc, the only effort involved is suffer some rebuilds. Unless you have a better idea I'll have look at patching glibc first. >> (define gnu-make-boot0 >>(package >> (inherit gnu-make) >> -(source (bootstrap-origin (package-source gnu-make))) >> +(version (if (hurd-system?) "4.1" >> + (package-version gnu-make))) >> +(source (if (hurd-system?) >> +(bootstrap-origin (package-source gnu-make-4.1)) >> +(bootstrap-origin (package-source gnu-make > > This won’t work as expected because ‘source’ is no thunked, and thus > (hurd-system?) is evaluated at the top level, when the module is > loaded. (IOW, if you do “-s i586-gnu” from GNU/Linux, it’ll go through > the wrong arm of the ‘if’.) Ah, crap! It seemed to work natively and with -t i586-pc-gnu ... (-s won't work anyway, right?) Hmm. janneke -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
Re: 23/33: gnu: commencement: gcc-boot0: Build fix for the Hurd.
On Tue, Mar 10, 2020 at 10:13:37AM +0100, Ludovic Courtès wrote:
> guix-comm...@gnu.org skribis:
>
> > commit 7a57ca758c590742b63100944f07fddb7290f797
> > Author: Jan Nieuwenhuizen
> > AuthorDate: Sun Mar 1 13:45:42 2020 +0100
> >
> > gnu: commencement: gcc-boot0: Build fix for the Hurd.
> >
> > Fixes:
> > g++ -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE
> > -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall
> > -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute
> > -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros
> > -Wno-overlength-strings -DHAVE_CONFIG_H -DGENERATOR_FILE -fno-PIE
> > -static-libstdc++ -static-libgcc
> > -Wl,-rpath=/gnu/store/vp2id82a597p119b3wyhhkhd467wvn78-glibc-bootstrap-0/lib
> > -Wl,-dynamic-linker -Wl,/gnu/store/vp2id82a597p119b3w [...]
> > build/genmddeps.o build/read-md.o build/errors.o
> > ../build-i586-unknown-gnu/libiberty/libiberty.a
> >
> > /gnu/store/jk3kx5jwjs9m60svzk6sz79bf0w33l91-binutils-cross-boot0-2.34/bin/ld:
> > build/read-md.o: in function `md_reader::~md_reader()':
> >
> > /tmp/guix-build-gcc-cross-boot0-7.5.0.drv-0/build/gcc/../../gcc-7.5.0/gcc/read-md.c:1049:
> > undefined reference to `operator delete(void*, unsigned int)'
> >
> > This raises the question: Should libstdc++-boot0 (v4.9) be sufficient
> > to build
> > gcc-boot0 (v7.5.0)?
>
> Hmm? :-)
>
> > * gnu/packages/commencement.scm (gcc-boot0): Add static library path.
>
> > `(,(string-append "LDFLAGS="
> > + (if ,(hurd-system?)
> > + (string-append
> > + "-L" (assoc-ref %build-inputs "gcc")
> > "/lib ")
> > + "")
>
> Could you add a comment saying that this is to allow the ‘delete’
> operator to be found? Weird.
>
> That’s it, thanks for the great work!
>
> Ludo’.
>
With the bootstrapping efforts going around there's a couple of patches
floating around to change the gcc version for libstdc++-boot0. I've
tested the following patch, which also prepares the way for any other
future supported platforms.
--
Efraim Flashner אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted
From 4506c48da7df4397d459337988adbdd54c0d440d Mon Sep 17 00:00:00 2001
From: Efraim Flashner
Date: Thu, 13 Feb 2020 10:47:34 +0200
Subject: [PATCH 1/2] gnu: libstdc++-boot0: Use per-architecture gcc versions.
* gnu/packages/commencement.scm (libstdc++-boot0): Use a version of gcc
more closely tied to their bootstrap process.
---
gnu/packages/commencement.scm | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/gnu/packages/commencement.scm b/gnu/packages/commencement.scm
index 2a0a83ad49..b5cb08a19a 100644
--- a/gnu/packages/commencement.scm
+++ b/gnu/packages/commencement.scm
@@ -3,7 +3,7 @@
;;; Copyright © 2014 Andreas Enge
;;; Copyright © 2012 Nikita Karetnikov
;;; Copyright © 2014, 2015, 2017 Mark H Weaver
-;;; Copyright © 2017, 2018, 2019 Efraim Flashner
+;;; Copyright © 2017, 2018, 2019, 2020 Efraim Flashner
;;; Copyright © 2018 Tobias Geerinckx-Rice
;;; Copyright © 2018 Jan (janneke) Nieuwenhuizen
;;; Copyright © 2019 Marius Bakke
@@ -1427,9 +1427,12 @@ exec " gcc "/bin/" program
(define libstdc++-boot0
;; GCC's libcc1 is always built as a shared library (the top-level
;; 'Makefile.def' forcefully adds --enable-shared) and thus needs to refer
- ;; to libstdc++.so. We cannot build libstdc++-5.3 because it relies on
- ;; C++14 features missing in some of our bootstrap compilers.
- (let ((lib (make-libstdc++ gcc-4.9)))
+ ;; to libstdc++.so. We therefore use a version of GCC which most closely
+ ;; matches the bootstrap compiler of that architecture.
+ (let ((lib (make-libstdc++
+ (match (%current-system)
+ ("aarch64-linux" gcc-5)
+ (_ gcc-4.9)
(package
(inherit lib)
(source (bootstrap-origin (package-source lib)))
--
2.25.0
signature.asc
Description: PGP signature
Re: About guix mirror build script
tumashu writes: > In China , guix substitute download seem to be to slow, > nearly unuseable. I have enabled an rsync daemon on ci.guix.gnu.org to share the “guix publish” cache. There are a few things missing: * not all files in /gnu/cache/guix can be read due to overly restrictive permissions generated by “guix publish” * having a copy of the cache alone is not enough. You’ll need to serve them like “guix publish” would. I haven’t looked closely enough, but it should be possible to serve this all statically. The first useful step, I believe, is to mirror the “guix publish” cache. -- Ricardo
Re: `guix build hello' now succeeds on the Hurd
Ricardo Wurmus writes: > Ludovic Courtès writes: > >> Anyhow, thumbs up! I’m looking forward to merging it and having it >> built on CI (we could offload to a Debian VM!)! > > My sentiments exactly! I’d be happy to put up a bunch of Debian > GNU/Hurd VMs on the nodes behind ci.guix.gnu.org. Thanks, yes that would be great! We just identified the wish to get make-4.3 to work; which could mean another couple of rebuild world rounds... janneke -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
Re: 05/33: gnu: hurd: Fix hurd-target?.
Ludovic Courtès writes: >> gnu: hurd: Fix hurd-target?. >> >> * gnu/packages/hurd.scm (hurd-target?): Bugfix; the arguments to >> string-suffix? to test (%current-system) were transposed, always >> resulting >> in #f. Use hurd-triplet?. > > Would be nice to squash with the previous one. :-) The previous/next hurd-system one, I guess.. :) done. -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
Re: 11/33: gnu: glibc: Add and update patches for the Hurd.
Ludovic Courtès writes: >> * gnu/packages/patches/glibc-hurd-clock_t_centiseconds.patch: New file. >> * gnu/packages/patches/glibc-hurd-clock_gettime_monotonic.patch: New >> file. >> * gnu/local.mk (dist_patch_DATA): Update them. >> * gnu/packages/base.scm (glibc): Use two new patches. > > [...] > >> -(patches (search-patches "glibc-ldd-x86_64.patch" >> +(patches `(,@(search-patches "glibc-ldd-x86_64.patch" > ^ > Superfluous. :-) Ah yes thanks, removed. (I had a number of patches that meant to avoid triggering rebuilds -- this is a leftover. >> + >> "glibc-hurd-clock_t_centiseconds.patch" >> + >> "glibc-hurd-clock_gettime_monotonic.patch") > > Nice patches! Did you submit them upstream? They are likely to be > applied quite quickly nowadays, so they could make it in glibc 2.32. > (It’s fine to carry them in the meantime, of course.) I "only" forward ported them, and fixed one; only to find the Debian glibc git archive just yesterday; so very similar ones are in Debian. It is unclear to me how that works, some are prefixed local-, others submitted- or unsubmitted-. I'll have to ask around. Worse, I just found what I meant to fix before with glibc-hurd-clock_gettime_monotonic.patch namely Fatal Python error: Py_Initialize: can't initialize time OSError: [Errno 1073741846] Invalid argument has somehow regressed...bah! Combining that with our make v4.1/v4.3 problem, I guess I'll need to dive into these Debian patches some more. Greetings, janneke -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
Re: 27/33: gnu: commencement: glibc-intermediate: Build fixes for the Hurd.
Ludovic Courtès writes:
>> + ,@(if (hurd-system?)
>> + `(map
>> + (lambda (f)
>> +(substitute* f
>
> ‘substitute*’ accepts a list of files, so you can write it like this:
>
> (substitute* '("sysdeps/mach/hurd/Makefile" "sysdeps/mach/Makefile")
> …)
Ah nice. Looking closer I see now that this also avoided rebuilds and
conveniently splices returns a list -- changed to
;; Tell 'libpthread' where to find 'libihash' on Hurd
systems.
,(when (hurd-system?)
'(substitute* '("sysdeps/mach/Makefile"
suffering a rebuild now anyway.
--
Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
Re: 33/33: daemon: Workaround issues for the Hurd.
Ludovic Courtès writes:
>> -#if CHROOT_ENABLED
>> +#if CHROOT_ENABLED || __GNU__
>
> Can we instead change the #define CHROOT_ENABLED such that
> CHROOT_ENABLED is always true when __GNU__? Also with a comment stating
> that GNU supports chroot(2) without being root.
I tried a couple of things and then remembered a patch by Manolis that
already does something like this; but nicer. So, I am now using that
patch and am only keeping this hack in the second patch (both attached)
>> +#if !__GNU__
>> int status = pid.wait(true);
>> if (status != 0)
>> throw Error(format("cannot kill processes for uid `%1%': %2%") %
>> uid % statusToString(status));
>> +#endif
>
> Do you know what the rationale was? It looks like it could leave
> zombies behind us.
No, maybe Manolis knows? What I do know is why I used the patch: before
applying this patch I could only build up to binutils-boot0.
binutils-boot0 would always fail like so
./pre-inst-env guix build -e '(@@ (gnu packages commencement)
binutils-boot0)' --no-offload
XXX fails: Workaround for nix daemon
phase `compress-documentation' succeeded after 0.4 seconds
error: cannot kill processes for uid `999': Operation not permitted
guix build: error: cannot kill processes for uid `999': failed with exit code 1
I haven't been seeing zombies but I'll watch for them now; don't know
what's going on here?
Greetings,
janneke
>From 0307646b22fc488e6342f5814fdef336dd154be3 Mon Sep 17 00:00:00 2001
From: Manolis Ragkousis
Date: Sun, 7 Aug 2016 17:48:30 +0300
Subject: [PATCH 1/2] daemon: Break CHROOT_ENABLED into smaller macros.
Checking for CLONE_NEWNS is only needed for using tha Linux specific clone(2),
otherwise we can use fork(2).
* nix/libstore/build.cc (CHROOT_ENABLED): Break into CHROOT_ENABLED
and CLONE_ENABLED.
(DerivationGoal::startBuilder): Replace CHROOT_ENABLED with CLONE_ENABLED.
(DerivationGoal::runChild): Only define pivot_root() if SYS_pivot_root is
defined.
---
nix/libstore/build.cc | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/nix/libstore/build.cc b/nix/libstore/build.cc
index 17e92c68a7..fc81e14cd1 100644
--- a/nix/libstore/build.cc
+++ b/nix/libstore/build.cc
@@ -52,7 +52,12 @@
#endif
-#define CHROOT_ENABLED HAVE_CHROOT && HAVE_SYS_MOUNT_H && defined(MS_BIND) && defined(MS_PRIVATE) && defined(CLONE_NEWNS) && defined(SYS_pivot_root)
+#define CHROOT_ENABLED HAVE_CHROOT && HAVE_SYS_MOUNT_H && defined(MS_BIND) && defined(MS_PRIVATE)
+#define CLONE_ENABLED defined(CLONE_NEWNS)
+
+#if defined(SYS_pivot_root)
+#define pivot_root(new_root, put_old) (syscall(SYS_pivot_root, new_root,put_old))
+#endif
#if CHROOT_ENABLED
#include
@@ -2005,7 +2010,7 @@ void DerivationGoal::startBuilder()
- The UTS namespace ensures that builders see a hostname of
localhost rather than the actual hostname.
*/
-#if CHROOT_ENABLED
+#if CLONE_ENABLED
if (useChroot) {
char stack[32 * 1024];
int flags = CLONE_NEWPID | CLONE_NEWNS | CLONE_NEWIPC | CLONE_NEWUTS | SIGCHLD;
@@ -2186,10 +2191,8 @@ void DerivationGoal::runChild()
if (mkdir("real-root", 0) == -1)
throw SysError("cannot create real-root directory");
-#define pivot_root(new_root, put_old) (syscall(SYS_pivot_root, new_root, put_old))
if (pivot_root(".", "real-root") == -1)
throw SysError(format("cannot pivot old root directory onto '%1%'") % (chrootRootDir + "/real-root"));
-#undef pivot_root
if (chroot(".") == -1)
throw SysError(format("cannot change root directory to '%1%'") % chrootRootDir);
--
2.24.0
>From f7a04d93f8ef43d56809dc7171b8e681982e2b51 Mon Sep 17 00:00:00 2001
From: Manolis Ragkousis
Date: Wed, 28 Dec 2016 02:49:22 +0200
Subject: [PATCH 2/2] daemon: Avoid killing issues for the Hurd.
This allows for native builds on the Hurd, doing
sudo ./pre-inst-env guix-daemon --disable-chroot --build-users-group=guixbuild &
./pre-inst-env guix build hello
XXX This works around
./pre-inst-env guix build -e '(@@ (gnu packages commencement) binutils-boot0)' --no-offload
phase `compress-documentation' succeeded after 0.4 seconds
error: cannot kill processes for uid `999': Operation not permitted
guix build: error: cannot kill processes for uid `999': failed with exit code 1
* nix/libutil/util.cc (killUser)[__GNU__]: Avoid wait failure.
---
nix/libutil/util.cc | 2 ++
1 file changed, 2 insertions(+)
diff --git a/nix/libutil/util.cc b/nix/libutil/util.cc
index fb2dfad1f7..df2cb1eb09 100644
--- a/nix/libutil/util.cc
+++ b/nix/libutil/util.cc
@@ -872,9 +872,11 @@ void killUser(uid_t uid)
_exit(0);
});
+#if !__GNU__
int status = pid.wait(true);
if (status != 0)
throw Error(format("cannot kill processes for uid `%1%': %2%") % uid % statusToString(status));
+#endif
/* !!! We should really do some check to make sure that there are
no processes left running
Re: 23/33: gnu: commencement: gcc-boot0: Build fix for the Hurd.
Efraim Flashner writes: > On Tue, Mar 10, 2020 at 10:13:37AM +0100, Ludovic Courtès wrote: >> guix-comm...@gnu.org skribis: >> >> > commit 7a57ca758c590742b63100944f07fddb7290f797 >> > Author: Jan Nieuwenhuizen >> > AuthorDate: Sun Mar 1 13:45:42 2020 +0100 >> > >> > gnu: commencement: gcc-boot0: Build fix for the Hurd. >> > >> > Fixes: >> > g++ -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE >> > -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall >> > -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute >> > -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros >> > -Wno-overlength-strings -DHAVE_CONFIG_H -DGENERATOR_FILE -fno-PIE >> > -static-libstdc++ -static-libgcc >> > -Wl,-rpath=/gnu/store/vp2id82a597p119b3wyhhkhd467wvn78-glibc-bootstrap-0/lib >> > -Wl,-dynamic-linker -Wl,/gnu/store/vp2id82a597p119b3w [...] >> > build/genmddeps.o build/read-md.o build/errors.o >> > ../build-i586-unknown-gnu/libiberty/libiberty.a >> > >> > /gnu/store/jk3kx5jwjs9m60svzk6sz79bf0w33l91-binutils-cross-boot0-2.34/bin/ld: >> > build/read-md.o: in function `md_reader::~md_reader()': >> > >> > /tmp/guix-build-gcc-cross-boot0-7.5.0.drv-0/build/gcc/../../gcc-7.5.0/gcc/read-md.c:1049: >> > undefined reference to `operator delete(void*, unsigned int)' >> > >> > This raises the question: Should libstdc++-boot0 (v4.9) be sufficient >> > to build >> > gcc-boot0 (v7.5.0)? >> >> Hmm? :-) >> >> > * gnu/packages/commencement.scm (gcc-boot0): Add static library path. >> >> > `(,(string-append "LDFLAGS=" >> > + (if ,(hurd-system?) >> > + (string-append >> > + "-L" (assoc-ref %build-inputs >> > "gcc") "/lib ") >> > + "") >> >> Could you add a comment saying that this is to allow the ‘delete’ >> operator to be found? Weird. >> >> That’s it, thanks for the great work! ... I agree, however trying without this and Efraim's patch instead first. > With the bootstrapping efforts going around there's a couple of patches > floating around to change the gcc version for libstdc++-boot0. I've > tested the following patch, which also prepares the way for any other > future supported platforms. That looks nice; thanks -- I have added i586-gnu and am trying if that works for me. janneke -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
Re: `guix build hello' now succeeds on the Hurd
Hello Jan, First of all awesome work!! On 3/10/20 10:59 AM, Jan Nieuwenhuizen wrote: > I briefly looked at more work-in-progress daemon patches by Manolis, but > stopped when I found that it needs [t]his "new" libhurdutils library... > @Manolis? > This is that work https://github.com/Phant0mas/Hurd/commit/3501ee22ad4150b3b2cf9a386d2350b9a68aecd8.patch It was working, needed some cleanup but it never got merged. What is does is implement mount and bind mounts using the hurd firmlinks. >> Merging what you have—the earlier the better. :-) >>> Shall I push this to savannah as `wip-hurd' (possibly save wip-hurd-> >>> `wip-hurd-old?); I don't think we need to keep the old wip-hurd. Just get rid of it. Manolis
Re: Guix-devel Digest, Vol 81, Issue 26
ve all every conditional avoided in these files is a win > in the not-so-long term. That’d be my guideline as we merge it. :-) > > Anyhow, thumbs up! I’m looking forward to merging it and having it > built on CI (we could offload to a Debian VM!)! > > Ludo’. > > > > -- > > Message: 4 > Date: Mon, 9 Mar 2020 10:48:53 -0700 > From: John Soo > To: Hartmut Goebel > Cc: Guix-devel > Subject: Re: rust (build system) deficits > Message-ID: > Content-Type: text/plain; charset=utf-8 > > Hi Hartmut, > > > My point is less the work, but the non-transitive declarations: > nettle-sys is an multi-indirect input for sequioa-sqv, still the later > needs to specify these dependencies. > > Totally agree. I think everyone agreed, too. A few months ago we decided > that the package inputs should match as close to exactly the dependencies > listed in Cargo.toml so as to avoid specifying transitive dependencies in > the package definition. > > The importer does solve the transitive dependencies but there is a bug. > Version numbers of cargo dependencies are not used which can sometimes > cause the problem you describe. I really hope the fixes get merged soon > because it is a real pain. > > > This importer does not solve the declarations, and IMHO it should not > anyway - as the are dependencies of another packages, which might change > over time. > > I’m not sure I fully understand why the recursive importer should not > solve the transitive dependencies. Could you elaborate further? > > If you are suggesting that guix refresh won’t pick up the changes, then I > think agree with you. That I believe is an artifact of using arguments > rather than inputs to specify dependencies. > > Kindly, > > John > > > -- > > Message: 5 > Date: Mon, 09 Mar 2020 19:11:34 +0100 > From: Ricardo Wurmus > To: guix-devel@gnu.org > Subject: Re: `guix build hello' now succeeds on the Hurd > Message-ID: <87o8t5o0tl@elephly.net> > Content-Type: text/plain; charset=utf-8 > > > Ludovic Courtès writes: > > > Anyhow, thumbs up! I’m looking forward to merging it and having it > > built on CI (we could offload to a Debian VM!)! > > My sentiments exactly! I’d be happy to put up a bunch of Debian > GNU/Hurd VMs on the nodes behind ci.guix.gnu.org. > > -- > Ricardo > > > > -- > > Message: 6 > Date: Mon, 9 Mar 2020 23:41:06 +0100 > From: Jan > To: Ricardo Wurmus > Cc: jbra...@dismail.de, guix-devel@gnu.org > Subject: Re: Thunar cannot launch gio-launch-desktop > Message-ID: <20200309234106.72ab8ce0@kompiuter> > Content-Type: text/plain; charset=US-ASCII > > Hello, > > it seems the issue is not Thunar-specific as Diego pointed out > https://lists.gnu.org/archive/html/guix-patches/2020-03/msg00291.html > I'm closing the issue then. > Cool wrapper exercise though :) > > > Jan Wielkiewicz > > > > -- > > Message: 7 > Date: Tue, 10 Mar 2020 10:32:23 +0800 (CST) > From: tumashu > To: guix > Subject: About guix mirror build script > Message-ID: <75a8a31c.2954.170c24939b1.coremail.tuma...@163.com> > Content-Type: text/plain; charset=UTF-8 > > In China , guix substitute download seem to be to slow, > nearly unuseable. > this week, I have found that NIX channels has been built China mirror > successful with the help of > 4 files: > > 1. https://github.com/tuna/tunasync-scripts/blob/master/nix.py > 2. https://github.com/tuna/tunasync-scripts/blob/master/nix-channels.py > 3. https://github.com/tuna/tunasync-scripts/blob/master/nixos-images.py > 4. > https://github.com/tuna/tunasync-scripts/blob/master/dockerfiles/nix-channels/Dockerfile > > guix is very similar nix, so I want to know how to port 4 files to work > with guix? > is it possible add similar tools to guix? > > -- > > Message: 8 > Date: Tue, 10 Mar 2020 08:48:05 +0100 > From: Gábor Boskovits > To: Veera > Cc: Guix-devel > Subject: Re: Hi, I am R Veera Kumar - Current Outreachy selected > Applicant > Message-ID: > pi5t8kpjrrthusgmbptwyao47xgpho8++z9xvqgvnv...@mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Hello, > > Veera ezt írta (időpont: 2020. márc. 8., Vas 8:41): > > > On Sat, Mar 07, 2020 at 09:31:32PM +0100, Gábor Boskovits wrote: > > > Hello Veera, > > > > > > Veera ezt írta (időpont: 2020. márc. 7., Szo 16:05): > > > > > > > Hi, > > > > > > > > I am R
Guix Data Services - Outreachy Applicant
Hello, This is Danjela, an outreachy applicant and a second year computer science student. How is everyone doing? I am trying to build the Guix Data Service project locally and it prompts me to install Guile-Squee. I tried to install Squee but I am running into other build problems when I run 'make'. Apparently it can't find libpq, which I checked and is downloaded. Here is the error message: ``` ice-9/boot-9.scm:752:25: In procedure dispatch-exception: In procedure dynamic-link: file: "libpq", message: "file not found" make[1]: *** [Makefile:968: squee.go] Error 1 make[1]: Leaving directory '/home/daniela/Downloads/guile-squee' make: *** [Makefile:543: all-recursive] Error 1 ``` I really want to start making some meaningful contributions to the project but don't know where to start or what sources to use in order to do so. I have to note that I am not using Gnu/Guix, but I do have the Guix package manager installed as well as a Gnu/Linux distro. (OpenSuse Tumbleweed) Any suggestion or help would be greatly appreciated by my side. Please don't hesitate to ask me further details if the description of the problem was to vague. Thank you,
Re: Hi, I am R Veera Kumar - Current Outreachy selected Applicant
On Tue, Mar 10, 2020 at 08:48:05AM +0100, Gábor Boskovits wrote: >Hello, >Veera <[1]v...@vkten.in> ezt írta (időpont: 2020. márc. 8., Vas 8:41): > > On Sat, Mar 07, 2020 at 09:31:32PM +0100, Gábor Boskovits wrote: > > > > To get started you should install guix. For this project it might > make > > sense to install guix system also. You should also set up a guix > > development environment, by checking out the source code, and > building it. > > > I am installing GuixSD. > >How did the install go? >Could you do it? Please feel free to reach out to me should you have >any questions. > Install from ISO did not go well. Could not complete install. So I tried VM img install and it is successfull. Now I am reading docs about guix. And how to get my way around. > > The usual first time contribution we recommend is to package an R > package > > from cran that has all its dependencies in guix using the > importer. > > > >Best regards, >G_bor > > References > >1. mailto:v...@vkten.in >3. http://issues.guix.gnu.org/easy Regards, Veera
Re: 02/02: gnu: next: Compress the executable.
Hi Pierre,
Pierre Neidhardt writes:
> Can you share your operating system declaration?
Sorry for the delay; here it is. I've anonymized some of the
information such as SSH public keys and usernames.
--8<---cut here---start->8---
;; This is an operating system configuration template
;; for a "desktop" setup with GNOME and Xfce where the
;; root partition is encrypted with LUKS.
(use-modules (guix store)
(gnu)
(gnu packages bash)
(gnu packages version-control)
(gnu system nss)
(srfi srfi-1))
(use-service-modules admin desktop docker linux ssh xorg)
(use-package-modules android certs docker java linux nfs ratpoison)
(define %my-desktop-services
(remove (lambda (service)
(eq? (service-kind service) gdm-service-type))
%desktop-services))
(operating-system
(host-name "myhost")
(timezone "America/Montreal")
(locale "en_US.utf8")
;; Choose US English keyboard layout. The "altgr-intl"
;; variant provides dead keys for accented characters.
(keyboard-layout (keyboard-layout "dvorak"))
;; Use the UEFI variant of GRUB with the EFI System
;; Partition mounted on /boot/efi.
(bootloader (bootloader-configuration
(bootloader grub-efi-bootloader)
(target "/boot/efi")
(keyboard-layout keyboard-layout)))
;; Specify a mapped device for the encrypted root partition.
;; The UUID is that returned by 'cryptsetup luksUUID'.
(mapped-devices
(list (mapped-device
(source (uuid "f85c0627-1f6f-48b9-a2c2-6c12594a7bd1"))
(target "btrfs-pool-1")
(type luks-device-mapping))
(mapped-device
(source (uuid "73b08e1a-ca2f-4d46-845a-3fe14cd7"))
(target "btrfs-pool-4")
(type luks-device-mapping
(file-systems (cons*
;; For EFI firmware.
(file-system
(device (uuid "209E-67AD" 'fat))
(mount-point "/boot/efi")
(type "vfat"))
;; Main system, on a 500 GB SSD (dev/sda).
(file-system
(device (file-system-label "btrfs-pool-1"))
(mount-point "/")
(type "btrfs")
(options "subvol=rootfs,compress=zstd")
(dependencies mapped-devices))
(file-system
(device (file-system-label "btrfs-pool-1"))
(mount-point "/home")
(type "btrfs")
(options "subvol=homefs,compress=zstd")
(dependencies mapped-devices))
;; 1000 GB drive for builds (/dev/nvme0n1). Shared
;; between jenkins-home, jenkins-build and
;; docker-cache subvolumes.
(file-system
(device (file-system-label "btrfs-pool-4"))
(mount-point "/home/jenkins-user")
(create-mount-point? #t)
(type "btrfs")
(options "subvol=jenkins-home,compress=zstd")
(dependencies mapped-devices))
(file-system
(device (file-system-label "btrfs-pool-4"))
(mount-point "/home/jenkins-user/workspace")
(create-mount-point? #t)
(type "btrfs")
(options "subvol=jenkins-build,compress=zstd")
(dependencies mapped-devices))
(file-system
(device (file-system-label "btrfs-pool-4"))
(mount-point "/var/lib/docker")
(create-mount-point? #t)
(type "btrfs")
(options "subvol=docker-cache,compress=zstd")
(dependencies mapped-devices))
;; NFS mounts for caching the state and downloads of
;; Yocto.
;; FIXME: Must be manually mounted.
(file-system
(device "server:/mnt/scratch/yocto-sstate")
(mount-point "/mnt/scratch/yocto-sstate")
(create-mount-point? #t)
(type "nfs")
(mount? #f)
(options "soft")
(flags '(no-exec)))
(file-system
(device "server:/mnt/scratch/yocto-dldir")
(mount-point "/mnt/scratch/yocto-dldir")
(create-mount-point? #t)
(type "nfs")
(mount? #f)
(options "soft")
(flags '(no-exec)))
%base-file-systems))
(swap-devices '("/swap/swapfile"))
(users (cons* (user-account
(name "myuser")
(group "users")
(supplementary-groups '("dialout" "wheel" "netdev"
