Re: Running guix-daemon as an unprivileged user (Was: [PATCH] syscalls: setns: Skip binding if there is no such C function.)
On Mon, Aug 17, 2015 at 10:57 PM, Eric Bavier wrote: >> Any patches related to bootstrapping gcc? I'm getting lib/lib64 confusion. > > > Yes, that's been one issue. > > Attached are the patches I have so far. Hopefully they can get you a bit > further. I've been able to build a number of packages, but thare are still > some package builds failing, e.g. IIRC one of cmake's dependencies doesn't > build. > > Some of these patches may be alright in general, but turning test cases off > is of course not an ideal solution. Great, thanks. My next ugly hand-cranked fix: $ ln -s /lib64/libnss_vas4.so.2 /home/myuser/.local/opt/guix/guix/store/llnj407l7gh3mz4jjsj6ymc6ph2a7hg6-glibc-2.21/lib/libnss_vas4.so.2 As nss plugins are a system-specific configuration and sysadmin-installed, I guess it could be argued that glibc *should* look in the system paths for them. On the other hand, there's no guarantee the stuff there will work for guix's glibc. In my case, luckily it did, and coreutils could pass its tests.
Re: [PATCH] syscalls: setns: Skip binding if there is no such C function.
Eric confirmed that this patch solved his issue so I've pushed it as commit 39e336b. - Dave
Re: Running guix-daemon as an unprivileged user (Was: [PATCH] syscalls: setns: Skip binding if there is no such C function.)
On 2015-08-17 15:46, Claes Wallin wrote:
On Mon, Aug 17, 2015 at 10:33 AM, Eric Bavier
wrote:
I have experimented with this a bit lately. It works to some extent,
but I have had to apply a few patches to some package recipes. Some
packages have failing tests (where presumably they would pass or be
skipped in the chroot), which I have disabled for the time being just
to move along.
I can post a few of the patches to the ML later.
Any patches related to bootstrapping gcc? I'm getting lib/lib64
confusion.
Yes, that's been one issue.
Attached are the patches I have so far. Hopefully they can get you a
bit further. I've been able to build a number of packages, but thare
are still some package builds failing, e.g. IIRC one of cmake's
dependencies doesn't build.
Some of these patches may be alright in general, but turning test cases
off is of course not an ideal solution.
--
`~Ericdiff --git a/gnu/packages/commencement.scm b/gnu/packages/commencement.scm
index 74c3f30..082b170 100644
--- a/gnu/packages/commencement.scm
+++ b/gnu/packages/commencement.scm
@@ -590,7 +590,9 @@ exec ~a/bin/~a-~a -B~a/lib -Wl,-dynamic-linker -Wl,~a/~a \"$@\"~%"
(if (string-prefix? "LDFLAGS=" flag)
(string-append flag " -L"
(assoc-ref %build-inputs "libstdc++")
- "/lib")
+ "/lib -L"
+ (assoc-ref %build-inputs "libstdc++")
+ "/lib64")
flag))
,flags)))
((#:phases phases)
diff --git a/gnu/packages/databases.scm b/gnu/packages/databases.scm
index cbac16e..766c16d 100644
--- a/gnu/packages/databases.scm
+++ b/gnu/packages/databases.scm
@@ -322,7 +322,9 @@ types are supported, as is encryption.")
other-digits))
6 #\0))
(string-append
-"mirror://sourceforge/sqlite.mirror/SQLite%20" version
+ "http://fossies.org/linux/misc";
+;; "mirror://sourceforge/sqlite.mirror/SQLite%20" version
+;; "http://sqlite.org/2015";
"/sqlite-autoconf-" numeric-version ".tar.gz")))
(sha256
(base32
diff --git a/gnu/packages/ghostscript.scm b/gnu/packages/ghostscript.scm
index 818072a..0492662 100644
--- a/gnu/packages/ghostscript.scm
+++ b/gnu/packages/ghostscript.scm
@@ -83,7 +83,7 @@ paper size.")
(version "17")
(source (origin
(method url-fetch)
-(uri "ftp://ftp.knackered.org/pub/psutils/psutils.tar.gz";)
+(uri "mirror://ctan/obsolete/support/psutils/psutils-p17.tar.gz")
(sha256 (base32
"1r4ab1fvgganm02kmm70b2r1azwzbav2am41gbigpa2bb1wynlrq"
(build-system gnu-build-system)
diff --git a/gnu/packages/linux.scm b/gnu/packages/linux.scm
index ba2879f..fdecaa7 100644
--- a/gnu/packages/linux.scm
+++ b/gnu/packages/linux.scm
@@ -483,6 +483,9 @@ providing the system administrator with some help in common tasks.")
(("/usr/") "/")
(("--(owner|group) 0") "")
(("ldconfig") "true")
+ (("lib64[[:blank:]]*:=(.*)$")
+ ;; Make sure libs are installed in lib
+ "lib64 := lib")
(("^LDFLAGS[[:blank:]]*:=(.*)$" _ value)
;; Add libproc to the RPATH.
(string-append "LDFLAGS := -Wl,-rpath="
@@ -1050,7 +1053,8 @@ advanced aspects of IP configuration (iptunnel, ipmaddr).")
(assoc-ref %outputs "out"))
"RAISE_SETFCAP=no")))
(native-inputs `(("perl" ,perl)))
-(inputs `(("attr" ,attr)))
+(inputs `(("attr" ,attr)
+ ("pam" ,linux-pam)))
(home-page "https://sites.google.com/site/fullycapable/";)
(synopsis "Library for working with POSIX capabilities")
(description
diff --git a/gnu/packages/nettle.scm b/gnu/packages/nettle.scm
index b20ddfa..26fa81a 100644
--- a/gnu/packages/nettle.scm
+++ b/gnu/packages/nettle.scm
@@ -40,7 +40,10 @@
(arguments
;; 'sexp-conv' and other programs need to have their RUNPATH point to
;; $libdir, which is not the case by default. Work around it.
- '(#:configure-flags (list (string-append "LDFLAGS=-Wl,-rpath="
+ '(#:configure-flags (list (string-append "--libdir="
+ (assoc-ref %outputs "out")
+ "/lib")
+ (string-append "LDFLAGS=-Wl,-rpath="
(assoc-ref %outputs "out")
"/lib"
(outputs '("out" "debug"))
diff --git a/gnu/packages/python.scm b/gnu/packages/python.scm
index 940efec..1eaea4a 100644
--- a/gnu/package
Re: Running guix-daemon as an unprivileged user (Was: [PATCH] syscalls: setns: Skip binding if there is no such C function.)
On Mon, Aug 17, 2015 at 10:57 PM, Eric Bavier wrote: > On 2015-08-17 15:46, Claes Wallin wrote: >> On Mon, Aug 17, 2015 at 10:33 AM, Eric Bavier >> wrote: >> >>> I have experimented with this a bit lately. It works to some extent, >>> but I have had to apply a few patches to some package recipes. Some >>> packages have failing tests (where presumably they would pass or be >>> skipped in the chroot), which I have disabled for the time being just >>> to move along. >>> >>> I can post a few of the patches to the ML later. >> >> >> >> Any patches related to bootstrapping gcc? I'm getting lib/lib64 confusion. > > > Yes, that's been one issue. > > Attached are the patches I have so far. Hopefully they can get you a bit > further. I've been able to build a number of packages, but thare are still > some package builds failing, e.g. IIRC one of cmake's dependencies doesn't > build. I saw more packages failing down the line due to ../lib64, e.g. procps, bison ... so I ended up patching gcc not to do ../lib64. Looks neater than adding defensive -L all over the place. How come this doesn't happen in the binary guix? Is this configuration a thing that is perpetuated from the system to gcc, and just nobody has been building the binary guix from scratch in a long time? Maybe each guix release should be built from scratch (if it isn't now), to make sure things like this don't live on unnoticed. > Some of these patches may be alright in general, but turning test cases off > is of course not an ideal solution. Still compiling libcs, gettexts and gccs now. Again. I'll see if I get far enough today to run into those issues. But I think once I get past glibc and gcc, I ought to be on par with binary guix. Right?
Re: Running guix-daemon as an unprivileged user (Was: [PATCH] syscalls: setns: Skip binding if there is no such C function.)
On Mon, Aug 17, 2015 at 10:33 AM, Eric Bavier wrote: > I have experimented with this a bit lately. It works to some extent, > but I have had to apply a few patches to some package recipes. Some > packages have failing tests (where presumably they would pass or be > skipped in the chroot), which I have disabled for the time being just > to move along. > > I can post a few of the patches to the ML later. Any patches related to bootstrapping gcc? I'm getting lib/lib64 confusion. /home/myuser/.local/opt/guix/guix/store/i901f9ad7j3cq7liaiszgpkcjs9mnw5p-libstdc++-4.9.3/lib64 *does* have a libstdc++.a. I'm doing the ugly thing for now. Just removing the empty lib and making it a symlink from lib64. g++ -g -DIN_GCC-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -DGENERATOR_FILE -Wl,-rpath=/home/myuser/.local/opt/guix/guix/store/llnj407l7gh3mz4jjsj6ymc6ph2a7hg6-glibc-2.21/lib -Wl,-dynamic-linker -Wl,/home/myuser/.local/opt/guix/guix/store/llnj407l7gh3mz4jjsj6ymc6ph2a7hg6-glibc-2.21/lib/ld-linux-x86-64.so.2 -L/home/myuser/.local/opt/guix/guix/store/i901f9ad7j3cq7liaiszgpkcjs9mnw5p-libstdc++-4.9.3/lib -o build/genmddeps \ build/genmddeps.o build/read-md.o build/errors.o ../build-x86_64-unknown-linux-gnu/libiberty/libiberty.a /home/myuser/.local/opt/guix/guix/store/i3s7jv6yfcmp04qjaj2m1v3pmbw6i2qr-binutils-cross-boot0-2.25/bin/x86_64-guix-linux-gnu-ld: cannot find -lstdc++ collect2: error: ld returned 1 exit status Makefile:2532: recipe for target 'build/genmddeps' failed make[3]: *** [build/genmddeps] Error 1 make[3]: Leaving directory '/tmp/nix-build-gcc-4.9.3.drv-0/build/gcc' Makefile:4229: recipe for target 'all-stage1-gcc' failed make[2]: *** [all-stage1-gcc] Error 2 make[2]: Leaving directory '/tmp/nix-build-gcc-4.9.3.drv-0/build' Makefile:21597: recipe for target 'stage1-bubble' failed make[1]: *** [stage1-bubble] Error 2 make[1]: Leaving directory '/tmp/nix-build-gcc-4.9.3.drv-0/build' Makefile:896: recipe for target 'all' failed make: *** [all] Error 2 phase `build' failed after 255 seconds builder for `/home/myuser/.local/opt/guix/guix/store/g6sf7j9a6sqallf0vlkdi4l313bdi2p7-gcc-4.9.3.drv' failed with exit code 1 @ build-failed /home/myuser/.local/opt/guix/guix/store/g6sf7j9a6sqallf0vlkdi4l313bdi2p7-gcc-4.9.3.drv - 1 builder for `/home/myuser/.local/opt/guix/guix/store/g6sf7j9a6sqallf0vlkdi4l313bdi2p7-gcc-4.9.3.drv' failed with exit code 1
Re: Running guix-daemon as an unprivileged user (Was: [PATCH] syscalls: setns: Skip binding if there is no such C function.)
On Mon, Aug 17, 2015 at 5:25 PM, Thompson, David wrote: > On Mon, Aug 17, 2015 at 11:16 AM, Claes Wallin (韋嘉誠) > wrote: >>> I think that to really make unprivileged use of Guix work acceptably, >>> we need to use the user namespaces feature first introduced in Linux >>> 3.8. This would allow unprivileged users to build software in the >>> same type of isolated environments that are used when running the >>> daemon as root. >> >> >> Working at all is acceptable to me. >> >> Do namespaces really work for non-root? That's more awesome than I >> expected. But without being able to point out how, it sounds to me >> like it could easily be a privilege escalation waiting to happen, >> unless you do it as compartmentalized as the Hurd does it ... which >> Linux won't. > > Yes, user namespaces can be created by unprivileged users. The user > that created the namespace then has root in the context of the new > namespace, which allows for creating all of the other types of > namespaces. There's been some bumps along the way, such as a security > bug with groups that prompted the addition of the > /proc//setgroups file in Linux 3.19 (I think) that has since been > backported to earlier kernel releases, the oldest I know of being > 3.13. But overall, this feature is very good and using it for Guix > would allow for the unprivileged daemon to take advantage of almost > all of the isolation techniques used by the privileged daemon. That is really awesome for all kinds of things. Wow. On this system though, setns doesn't exist, so I'm happy to get even a stow on steroids working, which actually seems to be the case at this point. Thank you all guix for making this awesome system! -- /c
Re: Running guix-daemon as an unprivileged user (Was: [PATCH] syscalls: setns: Skip binding if there is no such C function.)
On Mon, Aug 17, 2015 at 11:16 AM, Claes Wallin (韋嘉誠) wrote: > On Mon, Aug 17, 2015 at 4:34 PM, Thompson, David > wrote: >> On Mon, Aug 17, 2015 at 4:33 AM, Eric Bavier >> wrote: >>> On Mon, 17 Aug 2015 14:45:28 +0200 >>> Claes Wallin (韋嘉誠) wrote: > https://www.gnu.org/software/guix/manual/guix.html#Build-Environment-Setup "If you are installing Guix as an unprivileged user, it is still possible to run guix-daemon provided you pass --disable-chroot." >>> >>> I have experimented with this a bit lately. It works to some extent, >>> but I have had to apply a few patches to some package recipes. Some >>> packages have failing tests (where presumably they would pass or be >>> skipped in the chroot), which I have disabled for the time being just >>> to move along. >> >> I think that to really make unprivileged use of Guix work acceptably, >> we need to use the user namespaces feature first introduced in Linux >> 3.8. This would allow unprivileged users to build software in the >> same type of isolated environments that are used when running the >> daemon as root. > > > Working at all is acceptable to me. > > Do namespaces really work for non-root? That's more awesome than I > expected. But without being able to point out how, it sounds to me > like it could easily be a privilege escalation waiting to happen, > unless you do it as compartmentalized as the Hurd does it ... which > Linux won't. Yes, user namespaces can be created by unprivileged users. The user that created the namespace then has root in the context of the new namespace, which allows for creating all of the other types of namespaces. There's been some bumps along the way, such as a security bug with groups that prompted the addition of the /proc//setgroups file in Linux 3.19 (I think) that has since been backported to earlier kernel releases, the oldest I know of being 3.13. But overall, this feature is very good and using it for Guix would allow for the unprivileged daemon to take advantage of almost all of the isolation techniques used by the privileged daemon. - Dave
Re: Running guix-daemon as an unprivileged user (Was: [PATCH] syscalls: setns: Skip binding if there is no such C function.)
I'm almost done talking to myself, I promise. This is just all very exciting.
On Mon, Aug 17, 2015 at 4:31 PM, Claes Wallin (韋嘉誠)
wrote:
> On Mon, Aug 17, 2015 at 4:27 PM, Claes Wallin (韋嘉誠)
> wrote:
>
>> Now I'm doing this:
>>
>> git clean -fxd && # recover from previous attempts
>> git checkout HEAD . && # ditto
>> gettextize --po-dir=po{/guix,/packages,} &&
>> sed -re '/^[[:blank:]]*po\/(guix|packages)\/Makefile.in[[:blank:]]*$/d'
>> -i configure.ac && # because gettextize creates redundant entries for
>> these, over which alocal gets very upset
>> aclocal -I m4 &&
>> AUTOPOINT=true autoreconf -vi
>>
>>
>> And after a "LIBRARY_PATH=/home/myuser/.local/lib
>> CPATH=/home/myuser/.local/include ./configure
>> --prefix=/home/myuser/.local" it looks like I'm able to compile!
--prefix=/home/myuser/.local/opt/guix
I don't want stow and guix to control the same namespace.
> ice-9/boot-9.scm:106:20: In procedure # ice-9/boot-9.scm:97:6 (thrown-k . args)>:
> ice-9/boot-9.scm:106:20: In procedure dynamic-pointer: Symbol not found: setns
> make[2]: *** [guix/git-download.go] Error 1
>
> Right, not merged yet! I'll patch it locally ... So I might as well
> have done this on the tarball. Well well, I learned some autotools
> acrobatics on the way.
Patching worked, and ./pre-inst-env guix build bootstrap is now done
doing its massive downloads, made some kind of xz, bash and gcc etc,
and has started compiling glibc. Sweet. Maybe this is it. Fingers
crossed.
>> Thanks for putting up with my rubber-ducking.
>
> Doubly so.
Re: Running guix-daemon as an unprivileged user (Was: [PATCH] syscalls: setns: Skip binding if there is no such C function.)
On Mon, Aug 17, 2015 at 4:34 PM, Thompson, David wrote: > On Mon, Aug 17, 2015 at 4:33 AM, Eric Bavier > wrote: >> On Mon, 17 Aug 2015 14:45:28 +0200 >> Claes Wallin (韋嘉誠) wrote: >>> https://www.gnu.org/software/guix/manual/guix.html#Build-Environment-Setup >>> >>> "If you are installing Guix as an unprivileged user, it is still >>> possible to run guix-daemon provided you pass --disable-chroot." >>> >> >> I have experimented with this a bit lately. It works to some extent, >> but I have had to apply a few patches to some package recipes. Some >> packages have failing tests (where presumably they would pass or be >> skipped in the chroot), which I have disabled for the time being just >> to move along. > > I think that to really make unprivileged use of Guix work acceptably, > we need to use the user namespaces feature first introduced in Linux > 3.8. This would allow unprivileged users to build software in the > same type of isolated environments that are used when running the > daemon as root. Working at all is acceptable to me. Do namespaces really work for non-root? That's more awesome than I expected. But without being able to point out how, it sounds to me like it could easily be a privilege escalation waiting to happen, unless you do it as compartmentalized as the Hurd does it ... which Linux won't. -- /c
Re: Running guix-daemon as an unprivileged user (Was: [PATCH] syscalls: setns: Skip binding if there is no such C function.)
On Mon, Aug 17, 2015 at 4:33 AM, Eric Bavier wrote: > On Mon, 17 Aug 2015 14:45:28 +0200 > Claes Wallin (韋嘉誠) wrote: > >> On Sun, Aug 16, 2015 at 4:01 PM, Claes Wallin (韋嘉誠) >> wrote: >> > [Reposting with correct sender. Sorry, David.] >> > >> > Great! I ran into this when trying to compile and run guix on a >> > machine at work, where I'm not root. >> > >> > I was planning to run guix as a stow of steroids. But I'm still >> > wondering whether what I'm attempting is even intended to be >> > possible? Of course, I would lose the benefits of user separation, >> > chroot, hydra (because I can't write to /gnu) etc, but is guix even >> > made to be able to downgrade to this situation? >> >> Answering myself: It is there in the Fine Manual. So it's intended to >> work. I will try this and see how far I come. >> >> https://www.gnu.org/software/guix/manual/guix.html#Build-Environment-Setup >> >> "If you are installing Guix as an unprivileged user, it is still >> possible to run guix-daemon provided you pass --disable-chroot." >> > > I have experimented with this a bit lately. It works to some extent, > but I have had to apply a few patches to some package recipes. Some > packages have failing tests (where presumably they would pass or be > skipped in the chroot), which I have disabled for the time being just > to move along. I think that to really make unprivileged use of Guix work acceptably, we need to use the user namespaces feature first introduced in Linux 3.8. This would allow unprivileged users to build software in the same type of isolated environments that are used when running the daemon as root. - Dave
Re: Running guix-daemon as an unprivileged user (Was: [PATCH] syscalls: setns: Skip binding if there is no such C function.)
On Mon, Aug 17, 2015 at 3:42 PM, Claes Wallin (韋嘉誠)
wrote:
> On Mon, Aug 17, 2015 at 10:33 AM, Eric Bavier
> wrote:
>>> https://www.gnu.org/software/guix/manual/guix.html#Build-Environment-Setup
>>>
>>> "If you are installing Guix as an unprivileged user, it is still
>>> possible to run guix-daemon provided you pass --disable-chroot."
>>>
>>
>> I have experimented with this a bit lately. It works to some extent,
>> but I have had to apply a few patches to some package recipes. Some
>> packages have failing tests (where presumably they would pass or be
>> skipped in the chroot), which I have disabled for the time being just
>> to move along.
>>
>> I can post a few of the patches to the ML later.
>
> I'm doing this from git now, as opposed to doing it from the tarball
> earlier, because I want that setns patch.
>
> I have compiled gettext, m4, autoconf, automake and guile and its
> deps, installed in /home/myuser/.local.
And now I added sqlite and pkg-config as well, because looking at the
diff between tarball configure and my configure told me those were
missing. This helped me forward!
> Rather than run ./bootstrap, I've had to run gettextize, aclocal,
> autoreconf -vi (no -f!) with CPATH, LIBRARY_PATH and maybe AC_MACRODIR
> (probably not necessary), and I managed to get a ./configure, but it
> now tells me:
Now I'm doing this:
git clean -fxd && # recover from previous attempts
git checkout HEAD . && # ditto
gettextize --po-dir=po{/guix,/packages,} &&
sed -re '/^[[:blank:]]*po\/(guix|packages)\/Makefile.in[[:blank:]]*$/d'
-i configure.ac && # because gettextize creates redundant entries for
these, over which alocal gets very upset
aclocal -I m4 &&
AUTOPOINT=true autoreconf -vi
And after a "LIBRARY_PATH=/home/myuser/.local/lib
CPATH=/home/myuser/.local/include ./configure
--prefix=/home/eclewal/.local" it looks like I'm able to compile!
Thanks for putting up with my rubber-ducking.
Re: Running guix-daemon as an unprivileged user (Was: [PATCH] syscalls: setns: Skip binding if there is no such C function.)
On Mon, Aug 17, 2015 at 4:27 PM, Claes Wallin (韋嘉誠)
wrote:
> Now I'm doing this:
>
> git clean -fxd && # recover from previous attempts
> git checkout HEAD . && # ditto
> gettextize --po-dir=po{/guix,/packages,} &&
> sed -re '/^[[:blank:]]*po\/(guix|packages)\/Makefile.in[[:blank:]]*$/d'
> -i configure.ac && # because gettextize creates redundant entries for
> these, over which alocal gets very upset
> aclocal -I m4 &&
> AUTOPOINT=true autoreconf -vi
>
>
> And after a "LIBRARY_PATH=/home/myuser/.local/lib
> CPATH=/home/myuser/.local/include ./configure
> --prefix=/home/myuser/.local" it looks like I'm able to compile!
ice-9/boot-9.scm:106:20: In procedure #:
ice-9/boot-9.scm:106:20: In procedure dynamic-pointer: Symbol not found: setns
make[2]: *** [guix/git-download.go] Error 1
Right, not merged yet! I'll patch it locally ... So I might as well
have done this on the tarball. Well well, I learned some autotools
acrobatics on the way.
> Thanks for putting up with my rubber-ducking.
Doubly so.
Re: Running guix-daemon as an unprivileged user (Was: [PATCH] syscalls: setns: Skip binding if there is no such C function.)
On Mon, Aug 17, 2015 at 10:33 AM, Eric Bavier wrote: > On Mon, 17 Aug 2015 14:45:28 +0200 > Claes Wallin (韋嘉誠) wrote: >> On Sun, Aug 16, 2015 at 4:01 PM, Claes Wallin (韋嘉誠) >> wrote: >> > [Reposting with correct sender. Sorry, David.] >> > >> > Great! I ran into this when trying to compile and run guix on a >> > machine at work, where I'm not root. >> > >> > I was planning to run guix as a stow of steroids. But I'm still >> > wondering whether what I'm attempting is even intended to be >> > possible? Of course, I would lose the benefits of user separation, >> > chroot, hydra (because I can't write to /gnu) etc, but is guix even >> > made to be able to downgrade to this situation? >> >> Answering myself: It is there in the Fine Manual. So it's intended to >> work. I will try this and see how far I come. >> >> https://www.gnu.org/software/guix/manual/guix.html#Build-Environment-Setup >> >> "If you are installing Guix as an unprivileged user, it is still >> possible to run guix-daemon provided you pass --disable-chroot." >> > > I have experimented with this a bit lately. It works to some extent, > but I have had to apply a few patches to some package recipes. Some > packages have failing tests (where presumably they would pass or be > skipped in the chroot), which I have disabled for the time being just > to move along. > > I can post a few of the patches to the ML later. I'm doing this from git now, as opposed to doing it from the tarball earlier, because I want that setns patch. I have compiled gettext, m4, autoconf, automake and guile and its deps, installed in /home/myuser/.local. Rather than run ./bootstrap, I've had to run gettextize, aclocal, autoreconf -vi (no -f!) with CPATH, LIBRARY_PATH and maybe AC_MACRODIR (probably not necessary), and I managed to get a ./configure, but it now tells me: ./configure: line 6782: syntax error near unexpected token `GUILE,' ./configure: line 6782: `PKG_CHECK_MODULES(GUILE, guile-2.0 >= 2.0.7)' guile.m4 is there in my .../aclocal/guile.m4. I had to run aclocal manually, because otherwise it would say something about PKG_CHECK_MODULES being undefined. Seems like this little endeavor is hitting a lot of special cases.
Re: Running guix-daemon as an unprivileged user (Was: [PATCH] syscalls: setns: Skip binding if there is no such C function.)
On Mon, 17 Aug 2015 14:45:28 +0200 Claes Wallin (韋嘉誠) wrote: > On Sun, Aug 16, 2015 at 4:01 PM, Claes Wallin (韋嘉誠) > wrote: > > [Reposting with correct sender. Sorry, David.] > > > > Great! I ran into this when trying to compile and run guix on a > > machine at work, where I'm not root. > > > > I was planning to run guix as a stow of steroids. But I'm still > > wondering whether what I'm attempting is even intended to be > > possible? Of course, I would lose the benefits of user separation, > > chroot, hydra (because I can't write to /gnu) etc, but is guix even > > made to be able to downgrade to this situation? > > Answering myself: It is there in the Fine Manual. So it's intended to > work. I will try this and see how far I come. > > https://www.gnu.org/software/guix/manual/guix.html#Build-Environment-Setup > > "If you are installing Guix as an unprivileged user, it is still > possible to run guix-daemon provided you pass --disable-chroot." > I have experimented with this a bit lately. It works to some extent, but I have had to apply a few patches to some package recipes. Some packages have failing tests (where presumably they would pass or be skipped in the chroot), which I have disabled for the time being just to move along. I can post a few of the patches to the ML later. `~Eric
Re: Running guix-daemon as an unprivileged user (Was: [PATCH] syscalls: setns: Skip binding if there is no such C function.)
On Sun, Aug 16, 2015 at 4:01 PM, Claes Wallin (韋嘉誠) wrote: > [Reposting with correct sender. Sorry, David.] > > Great! I ran into this when trying to compile and run guix on a machine at > work, where I'm not root. > > I was planning to run guix as a stow of steroids. But I'm still wondering > whether what I'm attempting is even intended to be possible? Of course, I > would lose the benefits of user separation, chroot, hydra (because I can't > write to /gnu) etc, but is guix even made to be able to downgrade to this > situation? Answering myself: It is there in the Fine Manual. So it's intended to work. I will try this and see how far I come. https://www.gnu.org/software/guix/manual/guix.html#Build-Environment-Setup "If you are installing Guix as an unprivileged user, it is still possible to run guix-daemon provided you pass --disable-chroot." -- /c
Running guix-daemon as an unprivileged user (Was: [PATCH] syscalls: setns: Skip binding if there is no such C function.)
[Reposting with correct sender. Sorry, David.] Great! I ran into this when trying to compile and run guix on a machine at work, where I'm not root. I was planning to run guix as a stow of steroids. But I'm still wondering whether what I'm attempting is even intended to be possible? Of course, I would lose the benefits of user separation, chroot, hydra (because I can't write to /gnu) etc, but is guix even made to be able to downgrade to this situation?
Running guix-daemon as an unprivileged user (Was: [PATCH] syscalls: setns: Skip binding if there is no such C function.)
On 16-Aug-2015 2:19 pm, "David Thompson" wrote: Great! I ran into this when trying to compile and run guix on a machine at work, where I'm not root. I was planning to run guix as a stow of steroids. But I'm still wondering whether what I'm attempting is even intended to be possible? Of course, I would lose the benefits of user separation, chroot, hydra (because I can't write to /gnu) etc, but is guix even made to be able to downgrade to this situation?
[PATCH] syscalls: setns: Skip binding if there is no such C function.
>From 57faa1368cb96dd94cc32c18a0e6b63285ca8e1d Mon Sep 17 00:00:00 2001 From: David Thompson Date: Sun, 16 Aug 2015 08:08:34 -0400 Subject: [PATCH] syscalls: setns: Skip binding if there is no such C function. On systems with a glibc prior to 2.14, the 'setns' function is not available. Thanks to Eric Bavier for reporting the issue. * guix/build/syscalls.scm (setns): Wrap with 'false-if-exception'. --- guix/build/syscalls.scm | 23 +-- 1 file changed, 13 insertions(+), 10 deletions(-) diff --git a/guix/build/syscalls.scm b/guix/build/syscalls.scm index 68f340c..fc801a5 100644 --- a/guix/build/syscalls.scm +++ b/guix/build/syscalls.scm @@ -328,19 +328,22 @@ are shared between the parent and child processes." (proc syscall-id flags %null-pointer (define setns - (let* ((ptr (dynamic-func "setns" (dynamic-link))) - (proc (pointer->procedure int ptr (list int int -(lambda (fdes nstype) - "Reassociate the current process with the namespace specified by FDES, a + ;; Some systems may be using an old (pre-2.14) version of glibc where there + ;; is no 'setns' function available. + (false-if-exception + (let* ((ptr (dynamic-func "setns" (dynamic-link))) + (proc (pointer->procedure int ptr (list int int + (lambda (fdes nstype) + "Reassociate the current process with the namespace specified by FDES, a file descriptor obtained by opening a /proc/PID/ns/* file. NSTYPE specifies which type of namespace the current process may be reassociated with, or 0 if there is no such limitation." - (let ((ret (proc fdes nstype)) -(err (errno))) -(unless (zero? ret) - (throw 'system-error "setns" "~d ~d: ~A" - (list fdes nstype (strerror err)) - (list err))) + (let ((ret (proc fdes nstype)) + (err (errno))) + (unless (zero? ret) + (throw 'system-error "setns" "~d ~d: ~A" + (list fdes nstype (strerror err)) + (list err (define pivot-root (let* ((ptr (dynamic-func "pivot_root" (dynamic-link))) -- 2.4.3
