bug#50423: ‘certbot-configuration-deploy-hook’ is stateful
Hi,
I use certbot “deploy hooks” like this (excerpt from
‘hydra/bayfront.scm’ in guix/maintenance.git):
--8<---cut here---start->8---
(define %nginx-deploy-hook
;; Hook that restarts nginx when a new certificate is deployed.
(program-file "nginx-deploy-hook"
#~(let ((pid (call-with-input-file "/var/run/nginx/pid"
read)))
(kill pid SIGHUP
(define %certbot-configuration
(certbot-configuration
(webroot "/var/www")
(email "ludovic.cour...@inria.fr")
(certificates
(list (certificate-configuration
(domains '("bayfront.guix.gnu.org"
"logs.guix.gnu.org"
"bayfront.guix.info"
"hpc.guix.info"
"guix-hpc.bordeaux.inria.fr"
"coordinator.bayfront.guix.gnu.org"))
(deploy-hook %nginx-deploy-hook))
--8<---cut here---end--->8---
The problem is that cerbot records the deploy hook file name once for
all:
--8<---cut here---start->8---
ludo@bayfront ~$ sudo grep -r ryb6000fbb4lyb4ad294srkj4x8m821w /etc/letsencrypt/
Password:
/etc/letsencrypt/renewal/hpc.guix.info.conf:renew_hook =
/gnu/store/ryb6000fbb4lyb4ad294srkj4x8m821w-nginx-deploy-hook
/etc/letsencrypt/renewal/guix-hpc.bordeaux.inria.fr.conf:renew_hook =
/gnu/store/ryb6000fbb4lyb4ad294srkj4x8m821w-nginx-deploy-hook
--8<---cut here---end--->8---
After GC, the certbot config ends up pointing to a non-existing hook:
--8<---cut here---start->8---
ludo@bayfront ~$ sudo certbot renew
[...]
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Processing /etc/letsencrypt/renewal/hpc.guix.info.conf
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Renewing an existing certificate for hpc.guix.info
Hook 'deploy-hook' reported error code 127
Hook 'deploy-hook' ran with error output:
/gnu/store/pwcp239kjf7lnj5i4lkdzcfcxwcfyk72-bash-minimal-5.0.16/bin/sh:
/gnu/store/ryb6000fbb4lyb4ad294srkj4x8m821w-nginx-deploy-hook: No such file or
directory
--8<---cut here---end--->8---
Most likely, the only solution would be to populate a fixed directory
name, say /etc/nginx/hooks/deploy, such that certbot configuration
remains valid.
Thoughts?
Ludo’.
bug#49006: MELPA importer uses the wrong source when called from CLI
On Sun, Jun 13 2021, Xinglu Chen wrote:
> Okay, so new findings:
>
> When the (guix import elpa) module has been compiled, the generated
> package definition uses ‘url-fetch’ to fetch the source.
>
> --8<---cut here---start->8---
> ~/src/guix [env]$ ./pre-inst-env guix import elpa -a melpa magit
>
> Starting download of /tmp/guix-file.US750W
> From https://melpa.org/packages/magit-20210609.2000.tar...
> …609.2000.tar 1.7MiB365KiB/s 00:05 [##]
> 100.0%
> (package
> (name "emacs-magit")
> (version "20210609.2000")
> (source
> (origin
> (method url-fetch)
> (uri (string-append
> "https://melpa.org/packages/magit-";
> version
> ".tar"))
> (sha256
> (base32
> "0pplizxy20i3i9zqm5kfjz4la93gpz8wwh1ybwdwngv5ks7vhdsr"
> (build-system emacs-build-system)
> (propagated-inputs
> `(("emacs-dash" ,emacs-dash)
> ("emacs-git-commit" ,emacs-git-commit)
> ("emacs-magit-section" ,emacs-magit-section)
> ("emacs-transient" ,emacs-transient)
> ("emacs-with-editor" ,emacs-with-editor)))
> (home-page "https://github.com/magit/magit";)
> (synopsis "A Git porcelain inside Emacs.")
> (description
> "Magit is a text-based Git user interface that puts an unmatched focus
> on streamlining workflows. Commands are invoked using short mnemonic
> key sequences that take the cursor’s position in the highly actionable
> interface into account to provide context-sensitive behavior.
>
> With Magit you can do nearly everything that you can do when using Git
> on the command-line, but at greater speed and while taking advantage
> of advanced features that previously seemed too daunting to use on a
> daily basis. Many users will find that by using Magit they can become
> more effective Git user.
> ")
> (license #f))
> --8<---cut here---end--->8---
>
> However, if the (guix import elpa) module hasn’t been compiled, say I
> just add a dummy comment to it, then the generated package definition
> uses ‘git-fetch’ instead of ‘url-fetch’. Notice the messages emitted by
> Guile.
>
> --8<---cut here---start->8---
> ~/src/guix [env]$ ./pre-inst-env guix import elpa -a melpa magit
> ;;; note: source file /home/yoctocell/src/guix/guix/import/elpa.scm
> ;;; newer than compiled /home/yoctocell/src/guix/guix/import/elpa.go
> ;;; note: source file /home/yoctocell/src/guix/guix/import/elpa.scm
> ;;; newer than compiled
> /home/yoctocell/.config/guix/current/lib/guile/3.0/site-ccache/guix/import/elpa.go
> ;;; note: source file /home/yoctocell/src/guix/guix/import/elpa.scm
> ;;; newer than compiled
> /home/yoctocell/.guix-home/profile/lib/guile/3.0/site-ccache/guix/import/elpa.go
> ;;; note: source file /home/yoctocell/src/guix/guix/import/elpa.scm
> ;;; newer than compiled
> /home/yoctocell/.config/guix/current/lib/guile/3.0/site-ccache/guix/import/elpa.go
> ;;; note: source file /home/yoctocell/src/guix/guix/import/elpa.scm
> ;;; newer than compiled guix/import/elpa.go
> ;;; note: source file /home/yoctocell/src/guix/guix/import/elpa.scm
> ;;; newer than compiled
> /home/yoctocell/.cache/guile/ccache/3.0-LE-8-4.5/home/yoctocell/src/guix/guix/import/elpa.scm.go
> (package
> (name "emacs-magit")
> (version "20210609.2000")
> (source
> (origin
> (method git-fetch)
> (uri (git-reference
> (url "https://github.com/magit/magit.git";)
> (commit
>"71f57c5582448be81b02ba53750dd2ea39ed0eaf")))
> (sha256
> (base32
> "16ip50a46nk6xxj8qkpf6rmp28zjc1bhyjj9bfgibim8ywj87dlq"
> (build-system emacs-build-system)
> (propagated-inputs
> `(("emacs-dash" ,emacs-dash)
> ("emacs-git-commit" ,emacs-git-commit)
> ("emacs-magit-section" ,emacs-magit-section)
> ("emacs-transient" ,emacs-transient)
> ("emacs-with-editor" ,emacs-with-editor)))
> (arguments
> '(#:include
> '("^lisp/magit$"
> "^lisp/magit[^/]+.el$"
> "^lisp/git-rebase.el$"
> "^Documentation/magit.texi$"
> "^Documentation/AUTHORS.md$"
> "^LICENSE$")
> #:exclude
> '("^lisp/magit-libgit.el$"
> "^lisp/magit-section.el$")))
> (home-page "https://github.com/magit/magit";)
> (synopsis "A Git porcelain inside Emacs.")
> (description
> "Magit is a text-based Git user interface that puts an unmatched focus
> on streamlining workflows. Commands are invoked using short mnemonic
> key sequences that take the cursor’s position in the highly actionable
> interface into account to provide context-sensitive behavior.
>
> With Magit you can do nearly everything that you can do when using Git
> on the command-line, but at greater speed and while taking advantage
> of advanced features that previously seemed too daunting to use on
bug#50264: ca-certificate-bundle fails to build
Hi Ludo, thanks for looking into this! > Is this the backtrace found in the build log (under /var/log/guix/drvs)? Yes, it is printed on stdout, as well as part of the build log. > I tried and failed to reproduce it like this: > > --8<---cut here---start->8--- > $ guix environment --ad-hoc nss-certs -n > La jena derivo estus konstruata: >/gnu/store/i5s8jqzl52j38qmwqghjyp0v8p7dnlgd-profile.drv > > $ guix gc -R /gnu/store/i5s8jqzl52j38qmwqghjyp0v8p7dnlgd-profile.drv |grep > certificate > /gnu/store/n63a6h3dfhwnaas9pg35zk78qjhxbas9-cmake-curl-certificates.patch > /gnu/store/c8czsp9prfd73wvnyh595h0riqcllfqp-ca-certificate-bundle-builder > /gnu/store/wdnm4j88pxxkg0m72b58db24fghjizmz-ca-certificate-bundle.drv > $ guix build --rounds=10 > /gnu/store/wdnm4j88pxxkg0m72b58db24fghjizmz-ca-certificate-bundle.drv > … > --8<---cut here---end--->8--- > > Could you find a way to reproduce the issue? Alright, let’s see. The command I have been using is guix pack -L . -C 'zstd' -f docker -S /bin=bin python-jupyterlab bash coreutils findutils with . being a checkout of guix-science (same applies to `guix time-machine` though). The first time it’ll fail, but the second time it succeeds. Running `guix gc` makes it fail again the first time. The docker-pack.tar.zst.drv used for the first build is different from the second one (different hash prefix). For me it’s /gnu/store/r096cm3np7hbdn853ih35h1a5l39in4s-python-jupyterlab-bash-coreutils-docker-pack.tar.zst.drv the first time and /gnu/store/dywspxjshfjhc07i17hkcyrlq8kn7m07-python-jupyterlab-bash-coreutils-docker-pack.tar.zst.drv the second time. YMMV. Looking at ca-certificate-bundle.drv, the first one lacks any form of glibc-utf8-locales as an input (neither in the .drv, nor via `guix gc --references <.drv> | grep glibc-`), so it’s clear it must fail. I’m not quite sure why though, since the actual builder still has a reference to the locales and sets LOCPATH. So I’m a little puzzled. > --8<---cut here---start->8--- > $ guix build glibc-utf8-locales > /gnu/store/rgydar9dfvflqqz2irgh7njj34amaxc6-glibc-utf8-locales-2.31 > $ guix hash -r $(guix build glibc-utf8-locales) > 012a1vcvmhbrqr5kjbmf7qlgpbw2zv36rgj7rxh400dh8wlj97pi > $ wget -qO - https://ci.guix.gnu.org/rgydar9dfvflqqz2irgh7njj34amaxc6.narinfo > |grep NarHash > NarHash: sha256:012a1vcvmhbrqr5kjbmf7qlgpbw2zv36rgj7rxh400dh8wlj97pi > --8<---cut here---end--->8--- Exactly the same for me, so we have the same data at least. `guix gc` with the repair,contents options also does not show any corrupted items. I’m thus assuming my store is intact. Any ideas? Thanks, Lars
bug#50427: [core-updates-frozen] Guile 1.8.8 fails to build
Guile 1.8.8 (which has 16 dependents) fails to build on
‘core-updates-frozen’:
--8<---cut here---start->8---
cat alist.doc arbiters.doc async.doc backtrace.doc boolean.doc chars.doc
continuations.doc debug.doc deprecation.doc deprecated.doc discouraged.doc
dynl.doc dynwind.doc environments.doc eq.doc error.doc eval.doc evalext.doc
extensions.doc feature.doc fluids.doc fports.doc futures.doc gc.doc goops.doc
gsubr.doc gc-mark.doc gc-segment.doc gc-malloc.doc gc-card.doc guardians.doc
hash.doc hashtab.doc hooks.doc i18n.doc init.doc ioext.doc keywords.doc
lang.doc list.doc load.doc macros.doc mallocs.doc modules.doc numbers.doc
objects.doc objprop.doc options.doc pairs.doc ports.doc print.doc procprop.doc
procs.doc properties.doc random.doc rdelim.doc read.doc root.doc rw.doc
scmsigs.doc script.doc simpos.doc smob.doc sort.doc srcprop.doc stackchk.doc
stacks.doc stime.doc strings.doc srfi-4.doc srfi-13.doc srfi-14.doc
strorder.doc strports.doc struct.doc symbols.doc threads.doc throw.doc
values.doc variable.doc vectors.doc version.doc vports.doc weaks.doc ramap.doc
unif.doc dynl.doc filesys.doc posix.doc net_db.doc socket.doc regex-posix.doc |
GUILE="/tmp/guix-build-guile-1.8.8.drv-0/guile-1.8.8/pre-inst-guile"
../scripts/snarf-check-and-output-texi > guile-procedures.texi || { rm
guile-procedures.texi; false; }
/gnu/store/kq6p23qdfk0m3r6wf3c494kwnzv1vw8c-bash-minimal-5.1.8/bin/bash: line
1: 13557 Broken pipe cat alist.doc arbiters.doc async.doc
backtrace.doc boolean.doc chars.doc continuations.doc debug.doc deprecation.doc
deprecated.doc discouraged.doc dynl.doc dynwind.doc environments.doc eq.doc
error.doc eval.doc evalext.doc extensions.doc feature.doc fluids.doc fports.doc
futures.doc gc.doc goops.doc gsubr.doc gc-mark.doc gc-segment.doc gc-malloc.doc
gc-card.doc guardians.doc hash.doc hashtab.doc hooks.doc i18n.doc init.doc
ioext.doc keywords.doc lang.doc list.doc load.doc macros.doc mallocs.doc
modules.doc numbers.doc objects.doc objprop.doc options.doc pairs.doc ports.doc
print.doc procprop.doc procs.doc properties.doc random.doc rdelim.doc read.doc
root.doc rw.doc scmsigs.doc script.doc simpos.doc smob.doc sort.doc srcprop.doc
stackchk.doc stacks.doc stime.doc strings.doc srfi-4.doc srfi-13.doc
srfi-14.doc strorder.doc strports.doc struct.doc symbols.doc threads.doc
throw.doc values.doc variable.doc vectors.doc version.doc vports.doc weaks.doc
ramap.doc unif.doc dynl.doc filesys.doc posix.doc net_db.doc socket.doc
regex-posix.doc
13558 Segmentation fault |
GUILE="/tmp/guix-build-guile-1.8.8.drv-0/guile-1.8.8/pre-inst-guile"
../scripts/snarf-check-and-output-texi > guile-procedures.texi
make[3]: *** [Makefile:2175: guile-procedures.texi] Error 1
make[3]: Leaving directory
'/tmp/guix-build-guile-1.8.8.drv-0/guile-1.8.8/libguile'
make[2]: *** [Makefile:550: all] Error 2
--8<---cut here---end--->8---
Funny thing is that the crash is in its GC:
--8<---cut here---start->8---
Core was generated by
`/tmp/guix-build-guile-1.8.8.drv-0/guile-1.8.8/libguile/.libs/guile -l
../script'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 scm_mark_locations (x=0x7ffcacc396c8, n=18446744073709551554) at
gc-mark.c:435
435 SCM obj = * (SCM *) &x[m];
(gdb) bt
#0 scm_mark_locations (x=0x7ffcacc396c8, n=18446744073709551554) at
gc-mark.c:435
#1 0x7f3f1efb779d in scm_threads_mark_stacks () at threads.c:1408
#2 0x7f3f1ef6ffb8 in scm_mark_all () at gc-mark.c:82
#3 0x7f3f1ef6f8b1 in scm_i_gc (what=what@entry=0x7f3f1efd345f "cells") at
gc.c:596
#4 0x7f3f1ef6fab0 in scm_gc_for_newcell (freelist=0x7f3f1f006f80
, free_cells=0x1b8a350) at gc.c:507
#5 0x7f3f1efa111c in scm_double_cell (cdr=0, ccr=0, cbr=0, car=393767) at
../libguile/inline.h:201
#6 make_stringbuf (len=len@entry=6) at strings.c:116
#7 0x7f3f1efa1b05 in scm_i_c_make_symbol (name=name@entry=0x7f3f1efd7791
"caaddr", len=len@entry=6, flags=flags@entry=0,
hash=hash@entry=7051899415, props=0x7f3f1eab1fc0) at strings.c:433
#8 0x7f3f1efb62ea in scm_i_c_mem2symbol (name=name@entry=0x7f3f1efd7791
"caaddr", len=6) at symbols.c:150
#9 0x7f3f1efb6715 in scm_from_locale_symbol (sym=sym@entry=0x7f3f1efd7791
"caaddr") at symbols.c:388
#10 0x7f3f1ef93a36 in scm_c_make_subr (name=0x7f3f1efd7791 "caaddr",
type=type@entry=93, fcn=0xfa) at procs.c:69
#11 0x7f3f1ef93ad7 in scm_c_define_subr (name=,
type=type@entry=93, fcn=) at procs.c:80
#12 0x7f3f1ef8d6f2 in scm_init_pairs () at pairs.c:197
#13 0x7f3f1ef7d9f9 in scm_i_init_guile (base=base@entry=0x7ffcacc396c8) at
init.c:485
#14 0x7f3f1efb7482 in scm_i_init_thread_for_guile (parent=,
base=0x7ffcacc396c8) at threads.c:590
#15 scm_i_init_thread_for_guile (base=0x7ffcacc396c8, parent=)
at threads.c:573
#16 0x7f3f1efb752b in scm_i_with_guile_and_parent
(func=fu
bug#50433: shotcut 21.06.29 missing bin files
Hello, shotcut 21.06.29 (guix ce65f2b) appears to have missing bin files. When trying to export a video, the status of the task is "failed" inside the GUI, and below is the debug message on the terminal. [Debug ] "/gnu/store/qz8nr42ax7k3v0cysmh6afhmy93vvj82-shotcut-21.06.29/bin/melt-7 -verbose -progress2 -abort xml:%2Ftmp%2Fshotcut-xNVrrX.mlt" [Info ] job failed with 127 And here is the content of the bin directory : $ ls -la $(dirname $(realpath $(which shotcut))) total 3248 dr-xr-xr-x 2 root root 4096 1 janv. 1970 . dr-xr-xr-x 4 root root 4096 1 janv. 1970 .. -r-xr-xr-x 2 root root 1840 1 janv. 1970 shotcut -r-xr-xr-x 2 root root 1401 1 janv. 1970 .shotcut-real -r-xr-xr-x 2 root root 3308600 1 janv. 1970 ..shotcut-real-real
bug#50427: [core-updates-frozen] Guile 1.8.8 fails to build
Ludovic Courtès skribis: > Guile 1.8.8 (which has 16 dependents) fails to build on > ‘core-updates-frozen’: “Fixed” the hard way, by compiling with -O1, in b792bc899d4c88b8ccd50659c7dcccb3271200d1. I hope we can soon remove it. Ludo’.
bug#50353: Excessive temproots size when running guix build
Hi, Christopher Baines skribis: > I spotted a problem with data.guix.gnu.org trying to process this old > revision [1] > > 1: https://data.guix.gnu.org/revision/75dabac633bb9a33efbebf859f8aa4bb3b9582b2 > > The machine ran out of disk space, as a ~30GiB file had been created in > /var/guix/temproots. Sounds fishy. Those files contain a nul-separated list of GC roots (store file names). Thus, a file in there is proportional to the number of ‘add-temp-root’ RPCs made by the client during the session. A client with a long-running session (‘guix publish’, Coordinator, Data Service, Cuirass, etc.) that regularly adds temp roots makes that file grow endlessly. HTH! Ludo’.
bug#50441: Wrong build directory number shown in environment-variables file
I was doing guix build with "--keep-missing" and looking around in a few of the output directories. I was peeking in: /tmp/guix-build-u-boot-mnt-reform2-2021.06.drv-4 But wait... the "environment-variables" file says: #+BEGIN_SRC sh export TEMP=\ "/tmp/guix-build-u-boot-mnt-reform2-2021.06.drv-0" export TEMPDIR=\ "/tmp/guix-build-u-boot-mnt-reform2-2021.06.drv-0" export TMP=\ "/tmp/guix-build-u-boot-mnt-reform2-2021.06.drv-0" export TMPDIR=\ "/tmp/guix-build-u-boot-mnt-reform2-2021.06.drv-0" #+END_SRC Now wait a minute. Look at that last number. What the hell is going on here? Is this a bug in Guix? Why is it pointing at -0 in the -4 build directory? Does this point at a more serious issue? What's going on?
bug#50264: ca-certificate-bundle fails to build
For what it's worth, this same thing just happened to me when updating my profile on my laptop. The first time it failed exactly as described, and the second time it worked. Kyle
bug#50264: ca-certificate-bundle fails to build
On Mon Sep 6, 2021 at 6:18 PM CDT, Kyle Andrews wrote: > > For what it's worth, this same thing just happened to me when updating > my profile on my laptop. The first time it failed exactly as described, > and the second time it worked. > > Kyle I've also hit this twice in the last couple weeks. I just ran the updates again and they worked both times.
bug#50433: shotcut 21.06.29 missing bin files
Hello, Thanks for your report. Fulbert writes: > Hello, > > shotcut 21.06.29 (guix ce65f2b) appears to have missing bin files. When trying > to export a video, the status of the task is "failed" inside the GUI, and > below > is the debug message on the terminal. > > [Debug ] > "/gnu/store/qz8nr42ax7k3v0cysmh6afhmy93vvj82-shotcut-21.06.29/bin/melt-7 > -verbose -progress2 -abort xml:%2Ftmp%2Fshotcut-xNVrrX.mlt" > [Info ] job failed with 127 > > And here is the content of the bin directory : > > $ ls -la $(dirname $(realpath $(which shotcut))) > total 3248 > dr-xr-xr-x 2 root root 4096 1 janv. 1970 . > dr-xr-xr-x 4 root root 4096 1 janv. 1970 .. > -r-xr-xr-x 2 root root 1840 1 janv. 1970 shotcut > -r-xr-xr-x 2 root root 1401 1 janv. 1970 .shotcut-real > -r-xr-xr-x 2 root root 3308600 1 janv. 1970 ..shotcut-real-real I compared this to the release binaries and there really is just the one 'shotcut' executable. I think you're correct that the '127' error is due to it not finding an executable, but I think that's happening because shotcut got double-wrapped (or wrapped incorrectly). Unfortunately I'm not knowledgeable with qt-wrapping so I can't help any further, but I hope that helps! -- Sarah
bug#50441: Wrong build directory number shown in environment-variables file
Christine, Christine Lemmer-Webber 写道： I was doing guix build with "--keep-missing" and looking around in a few of the output directories. I was peeking in: /tmp/guix-build-u-boot-mnt-reform2-2021.06.drv-4 But wait... the "environment-variables" file says: #+BEGIN_SRC sh export TEMP=\ "/tmp/guix-build-u-boot-mnt-reform2-2021.06.drv-0" Part of the build environment isolation/reproducibility is that processes inside it always see a build directory ending in ‘-0’, regardless of the file name on the host system. Kind regards, T G-R signature.asc Description: PGP signature
bug#50441: Wrong build directory number shown in environment-variables file
Hello Christine,
Christine Lemmer-Webber writes:
> I was doing guix build with "--keep-missing" and looking around in a few
> of the output directories. I was peeking in:
>
> /tmp/guix-build-u-boot-mnt-reform2-2021.06.drv-4
>
> But wait... the "environment-variables" file says:
>
> #+BEGIN_SRC sh
> export TEMP=\
> "/tmp/guix-build-u-boot-mnt-reform2-2021.06.drv-0"
> export TEMPDIR=\
> "/tmp/guix-build-u-boot-mnt-reform2-2021.06.drv-0"
> export TMP=\
> "/tmp/guix-build-u-boot-mnt-reform2-2021.06.drv-0"
> export TMPDIR=\
> "/tmp/guix-build-u-boot-mnt-reform2-2021.06.drv-0"
> #+END_SRC
>
> Now wait a minute. Look at that last number. What the hell is going on
> here? Is this a bug in Guix? Why is it pointing at -0 in the -4 build
> directory?
>
> Does this point at a more serious issue? What's going on?
I've definitely noticed this before as well, and had to work around it
(I needed to inspect temp caches). Thanks for actually sending a bug
report :)
I'm not at all familiar with the nix code, but it looks like this might
be related:
nix/libstore/build.cc:1654
--8<---cut here---start->8---
/* In a sandbox, for determinism, always use the same temporary
directory. */
tmpDirInSandbox = useChroot ? canonPath("/tmp", true) + "/guix-build-" +
drvName + "-0" : tmpDir;
/* For convenience, set an environment pointing to the top build
directory. */
env["NIX_BUILD_TOP"] = tmpDirInSandbox;
/* Also set TMPDIR and variants to point to this directory. */
env["TMPDIR"] = env["TEMPDIR"] = env["TMP"] = env["TEMP"] = tmpDirInSandbox;
/* Explicitly set PWD to prevent problems with chroot builds. In
particular, dietlibc cannot figure out the cwd because the
inode of the current directory doesn't appear in .. (because
getdents returns the inode of the mount point). */
env["PWD"] = tmpDirInSandbox;
--8<---cut here---end--->8---
I'm not entirely sure what's going on. I think we build in chroot by
default, which would explain why the temp vars get set to "-0" even
though everything else seems to work okay.
--
Sarah
