bug#30265: Fish shell has wrong path variables
Hi, I am using GuixSD 0.14. After upgrading fish shell to latest version(v2.7.1) and running `guix gc`, fish shell does not work well. #+BEGIN_EXAMPLE meiyo@guix ~$ fish fish: echo $_ " "; __fish_pwd ^ in command substitution called on standard input fish: __fish_pwd ^ in command substitution called on standard input in command substitution called on standard input fish: echo $_ " "; __fish_pwd ^ in command substitution called on standard input #+END_EXAMPLE __fish_pwd is a fish function. It's defined in `share/fish/functions/__fish_pwd.fish`. The error message shows that fish cannot load __fish_pwd's function definition from disk. After doing some research, I found out that the error was caused by wrong environment variables. Fish shell is installed in: #+BEGIN_EXAMPLE /gnu/store/ajbbi9cgj9j0my7v5habp0lcysaf2a51-fish-2.7.1/ #+END_EXAMPLE But the environment variable $fish_function_path does not exist. And these environment variables point to non-existent paths: #+BEGIN_EXAMPLE __fish_bin_dir /gnu/store/4jkxcz8kpy621ycmqn3rvs0fv6c98h6p-fish-2.7.1/bin __fish_datadir /gnu/store/4jkxcz8kpy621ycmqn3rvs0fv6c98h6p-fish-2.7.1/share/fish #+END_EXAMPLE Setting $fish_function_path to the correct path reduces the error message. #+BEGIN_EXAMPLE set fish_function_path /gnu/store/ajbbi9cgj9j0my7v5habp0lcysaf2a51-fish-2.7.1/share/fish/functions #+END_EXAMPLE `share/fish/config.fish` states $__fish_datadir is set by fish.cpp, and $fish_function_path is derived from $__fish_datadir. #+BEGIN_SRC fish # __fish_datadir, __fish_sysconfdir, __fish_help_dir, __fish_bin_dir # are expected to have been set up by read_init from fish.cpp # Set up function and completion paths. Make sure that the fish # default functions/completions are included in the respective path. if not set -q fish_function_path set fish_function_path $configdir/fish/functions $__fish_sysconfdir/functions $__extra_functionsdir $__fish_datadir/functions end if not contains -- $__fish_datadir/functions $fish_function_path set fish_function_path $fish_function_path $__fish_datadir/functions end #+END_SRC In conclusion, I think some path related variables are not set correctly when fish is compiled from source code and that caused the bug I met. But since I'm not good at C++ programming, I will not dive deeper. I hope that the information provided above is helpful. Meiyo Peng
bug#23199: XFCE is missing documentation
In my opinion this bug can be closed due to WONTFIX from upstream at this URL: > https://docs.xfce.org/contribute/documentation quote: >> Documentation >> Introduction >> Since Xfce 4.10 there are no application manuals in the >> packages. Reason for this change is that hardly any >> documentation was contributed over the years mainly because >> people had problems with the various formats (docbook and >> mallard) or with the complexity of the VCS1). >> >> To make the documentation barrier lower it was decided to start >> a documentation wiki where contributors, developers and >> translators can work on good and up-to-date documentation. >> >> From the various dialogs and links in the Xfce applications, >> we redirect to the sections in this wiki. So, we won't see any offline Documentation here. I've looked at 3 other OS before reading this, and none of the do anything different wrt Manual including/excluding. With this in mind, I'm closing the bug report. -- ng0 :: https://ea.n0.is A88C8ADD129828D7EAC02E52E22F9BBFEE348588 :: https://ea.n0.is/keys/
bug#30265: Fish shell has wrong path variables
Hi Meiyo, thanks for your report. Indeed, Fish has some problems in Guix. On Sat, 27 Jan 2018, Meiyo Peng wrote: > Hi, > > I am using GuixSD 0.14. After upgrading fish shell to latest version(v2.7.1) > and > running `guix gc`, fish shell does not work well. Can you explain a bit more about your setup? I assume you use fish as you user shell and not just as a shell you switch into from a Bash enabled user, correct? > #+BEGIN_EXAMPLE > meiyo@guix ~$ fish > fish: > echo $_ " "; __fish_pwd >^ > in command substitution > called on standard input > > fish: > __fish_pwd > ^ > in command substitution > called on standard input > > in command substitution > called on standard input > > fish: > echo $_ " "; __fish_pwd >^ > in command substitution > called on standard input > #+END_EXAMPLE > > > __fish_pwd is a fish function. It's defined in > `share/fish/functions/__fish_pwd.fish`. The error message shows that fish > cannot load __fish_pwd's function definition from disk. After doing some > research, I found out that the error was caused by wrong environment > variables. > > Fish shell is installed in: > > #+BEGIN_EXAMPLE > /gnu/store/ajbbi9cgj9j0my7v5habp0lcysaf2a51-fish-2.7.1/ > #+END_EXAMPLE > > > But the environment variable $fish_function_path does not exist. And these > environment variables point to non-existent paths: > > #+BEGIN_EXAMPLE > __fish_bin_dir /gnu/store/4jkxcz8kpy621ycmqn3rvs0fv6c98h6p-fish-2.7.1/bin > __fish_datadir > /gnu/store/4jkxcz8kpy621ycmqn3rvs0fv6c98h6p-fish-2.7.1/share/fish > #+END_EXAMPLE > > > Setting $fish_function_path to the correct path reduces the error message. > > #+BEGIN_EXAMPLE > set fish_function_path > /gnu/store/ajbbi9cgj9j0my7v5habp0lcysaf2a51-fish-2.7.1/share/fish/functions > #+END_EXAMPLE > > > `share/fish/config.fish` states $__fish_datadir is set by fish.cpp, > and $fish_function_path is derived from $__fish_datadir. > > #+BEGIN_SRC fish > # __fish_datadir, __fish_sysconfdir, __fish_help_dir, __fish_bin_dir > # are expected to have been set up by read_init from fish.cpp > > > # Set up function and completion paths. Make sure that the fish > # default functions/completions are included in the respective path. > > if not set -q fish_function_path > set fish_function_path $configdir/fish/functions > $__fish_sysconfdir/functions $__extra_functionsdir $__fish_datadir/functions > end > > if not contains -- $__fish_datadir/functions $fish_function_path > set fish_function_path $fish_function_path $__fish_datadir/functions > end > #+END_SRC > > In conclusion, I think some path related variables are not set correctly when > fish is compiled from source code and that caused the bug I met. But since I'm > not good at C++ programming, I will not dive deeper. > > I hope that the information provided above is helpful. > > > Meiyo Peng It's more or less known, I assume this is related to bug#27206 https://debbugs.gnu.org/cgi/bugreport.cgi?bug=27206 Which to my knowledge and sources I've read doesn't require C knowledge but more knowledge of how Fish interacts on system/vendor level and some testing with the resources I've provided in the other thread/bug. -- ng0 :: https://ea.n0.is A88C8ADD129828D7EAC02E52E22F9BBFEE348588 :: https://ea.n0.is/keys/
bug#30265: Fish shell has wrong path variables
Hi Meiyo, thanks for the report. > I am using GuixSD 0.14. After upgrading fish shell to latest version(v2.7.1) > and > running `guix gc`, fish shell does not work well. […] > Fish shell is installed in: > #+BEGIN_EXAMPLE > /gnu/store/ajbbi9cgj9j0my7v5habp0lcysaf2a51-fish-2.7.1/ > #+END_EXAMPLE > > But the environment variable $fish_function_path does not exist. And these > environment variables point to non-existent paths: > #+BEGIN_EXAMPLE > __fish_bin_dir /gnu/store/4jkxcz8kpy621ycmqn3rvs0fv6c98h6p-fish-2.7.1/bin > __fish_datadir > /gnu/store/4jkxcz8kpy621ycmqn3rvs0fv6c98h6p-fish-2.7.1/share/fish > #+END_EXAMPLE Where are these environment variables defined? > In conclusion, I think some path related variables are not set > correctly when fish is compiled from source code and that caused the > bug I met. Some other packages record exact store references in cache files in the user’s home directory. As packages get upgraded and removed after garbage collection, these references become invalid. The question is whether these old store references are kept in files outside of the store (and thus are not directly under our control), or if the packages that Guix builds include incorrect references. I guess that it’s the former. As is the case for these other programmes that record paths in cache files, we would need to patch fish to record only the stable names of links to those files (e.g. ~/.guix-profile/foo/bar) rather than the actual file names in the store, which may disappear upon “guix gc”. -- Ricardo GPG: BCA6 89B6 3655 3801 C3C6 2150 197A 5888 235F ACAC https://elephly.net
bug#30265: Fish shell has wrong path variables
Ricardo Wurmus writes: > Where are these environment variables defined? According to `share/fish/config.fish`, they are defined in fish.cpp. #+BEGIN_SRC fish # __fish_datadir, __fish_sysconfdir, __fish_help_dir, __fish_bin_dir # are expected to have been set up by read_init from fish.cpp #+END_SRC You can get fish shell's environment variables using fish's `set` command. A single `set` without argument will print all environment variables. > The question is whether these old store references are kept in files > outside of the store (and thus are not directly under our control), or > if the packages that Guix builds include incorrect references. I guess > that it’s the former. > > As is the case for these other programmes that record paths in cache > files, we would need to patch fish to record only the stable names of > links to those files (e.g. ~/.guix-profile/foo/bar) rather than the > actual file names in the store, which may disappear upon “guix gc”. > Maybe you are right. Guix is still new to me, so I do not know details about guix's mechanism. Meiyo Peng
bug#30265: Fish shell has wrong path variables
ng0 wrote: > Can you explain a bit more about your setup? I assume you use > fish as you user shell and not just as a shell you switch into > from a Bash enabled user, correct? My GuixSD is a fresh setup. I did no customization to fish and did not set fish as login shell. The bug I reported is reproducible. I tried it in a virtual machine several times. 1. Install GuixSD 0.14 with fish 2. guix pull 3. Upgrade all packages 4. guix gc 5. Start a fish shell, and the bug I reported occur
bug#30250: Two failures on ‘make -k "-j$(nproc)" check’
Hi Jorge,
"Jorge" skribis:
> I use ntlmaps (listening on localhost:5865) to mediate the corporate proxy
> for programs that do not integrate with Gnome's proxy configuration
> ==
>GNU Guix 0.14.0.1193-4f34e: ./test-suite.log
> ==
>
> # TOTAL: 744
> # PASS: 718
> # SKIP: 24
> # XFAIL: 0
> # FAIL: 2
> # XPASS: 0
> # ERROR: 0
[...]
> test-name: add-to-store, flat
> location: /home/jorge/repos/guix/tests/derivations.scm:98
> source:
> + (test-assert
> + "add-to-store, flat"
> + (let* ((file (search-path
> + %load-path
> + "language/tree-il/spec.scm"))
> + (drv (add-to-store
> + %store
> + "flat-test"
> + #f
> + "sha256"
> + file)))
> + (and (eq? 'regular (stat:type (stat drv)))
> + (valid-path? %store drv)
> + (equal?
> +(call-with-input-file file get-bytevector-all)
> +(call-with-input-file drv get-bytevector-all)
> actual-value: #f
> actual-error:
> + (srfi-34
> + # 1] 5577e11973c0>)
> result: FAIL
It looks like the language/tree-il/spec.scm file (which is part of
Guile) that was found in $GUILE_LOAD_PATH on your system is not a
regular file and is instead presumably a symlink. Could you check that
this is the case?
The solution would be for it to be a regular file and/or for the test to
check that.
> test-name: 'download' built-in builder
> location: /home/jorge/repos/guix/tests/derivations.scm:227
> source:
> + (test-assert
> + "'download' built-in builder"
> + (let ((text (random-text)))
> + (with-http-server
> + 200
> + text
> + (let* ((drv (derivation
> + %store
> + "world"
> + "builtin:download"
> + '()
> + #:env-vars
> + `(("url" unquote (object->string (%local-url
> + #:hash-algo
> + 'sha256
> + #:hash
> + (sha256 (string->utf8 text)
> + (and (build-derivations %store (list drv))
> + (string=?
> +(call-with-input-file
> + (derivation->output-path drv)
> + get-string-all)
> +text))
> @ build-started
> /home/jorge/repos/guix/test-tmp/store/24ibbvll6jdr9ri6qp7z1vgcl4vjljwv-world.drv
> - x86_64-linux
> /home/jorge/repos/guix/test-tmp/var/log/guix/drvs/24//ibbvll6jdr9ri6qp7z1vgcl4vjljwv-world.drv.bz2
>
> Starting download of
> /home/jorge/repos/guix/test-tmp/store/25k9f37z2l775rbj4kianf5g1k9vnczj-world
> From http://localhost:10500/foo/bar...
> download failed "http://localhost:10500/foo/bar"; 503 "Service Unavailable"
> failed to download
> "/home/jorge/repos/guix/test-tmp/store/25k9f37z2l775rbj4kianf5g1k9vnczj-world"
> from "http://localhost:10500/foo/bar";
> builder for
> `/home/jorge/repos/guix/test-tmp/store/24ibbvll6jdr9ri6qp7z1vgcl4vjljwv-world.drv'
> failed to produce output path
> `/home/jorge/repos/guix/test-tmp/store/25k9f37z2l775rbj4kianf5g1k9vnczj-world'
> @ build-failed
> /home/jorge/repos/guix/test-tmp/store/24ibbvll6jdr9ri6qp7z1vgcl4vjljwv-world.drv
> - 1 builder for
> `/home/jorge/repos/guix/test-tmp/store/24ibbvll6jdr9ri6qp7z1vgcl4vjljwv-world.drv'
> failed to produce output path
> `/home/jorge/repos/guix/test-tmp/store/25k9f37z2l775rbj4kianf5g1k9vnczj-world'
> actual-value: #f
> actual-error:
> + (srfi-34
> + # `/home/jorge/repos/guix/test-tmp/store/24ibbvll6jdr9ri6qp7z1vgcl4vjljwv-world.drv'
> failed" status: 1] 5577e21fdde0>)
> result: FAIL
This test runs its own HTTP server on port 10500. Could it be that it
try to go through your proxy and failed? Can you check whether this
works:
unset http_proxy
make check TESTS=tests/derivations.scm
?
Thanks for your report!
Ludo’.
bug#30265: Fish shell has wrong path variables
Hi ng0 and Meiyo, n...@n0.is skribis: > On Sat, 27 Jan 2018, Meiyo Peng wrote: >> Hi, >> >> I am using GuixSD 0.14. After upgrading fish shell to latest version(v2.7.1) >> and >> running `guix gc`, fish shell does not work well. > > Can you explain a bit more about your setup? I assume you use > fish as you user shell and not just as a shell you switch into > from a Bash enabled user, correct? Note that the current ‘guix’ package, 0.14.0-7.33988f9, includes Fish completion support, which was not the case before: --8<---cut here---start->8--- $ ls -R $(guix build guix)/share/fish /gnu/store/apji9j8cwf9xpd5jk5mk8s6r1a391yvq-guix-0.14.0-7.33988f9/share/fish: vendor_completions.d /gnu/store/apji9j8cwf9xpd5jk5mk8s6r1a391yvq-guix-0.14.0-7.33988f9/share/fish/vendor_completions.d: guix.fish --8<---cut here---end--->8--- Could it be the reason why you’re having problems now that you didn’t experience earlier? Any ideas, ng0? Thanks, Ludo’.
bug#30270: [PATCH] url-fetch returns #t instead of FILE
Hello! Commit 347fa4aebf, introduced a regression where `url-fetch' would return #t instead of the file name (as the docstring says it should), which broke the fiasco script used to find broken hashes of Github's archives[0]. Patch to follow. [0] https://notabug.org/apteryx/fiasco
bug#30270: [PATCH] url-fetch returns #t instead of FILE
Maxim Cournoyer writes: > Hello! > > Commit 347fa4aebf, introduced a regression where `url-fetch' would return #t > instead of the file name (as the docstring says it should), which broke > the fiasco script used to find broken hashes of Github's archives[0]. > > Patch to follow. ^ >From 61ca016f3a2a6504d899a6ec3b9daaf1647be451 Mon Sep 17 00:00:00 2001 From: Maxim Cournoyer Date: Sat, 27 Jan 2018 12:22:11 -0500 Subject: [PATCH] download: Fix return value of the url-fetch procedure. Fixes #30270 which was introduced by commit 347fa4aebf. * guix/build/download.scm (url-fetch): Return `file' instead of #t upon success. --- guix/build/download.scm | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/guix/build/download.scm b/guix/build/download.scm index 609a10053..1b630a9d6 100644 --- a/guix/build/download.scm +++ b/guix/build/download.scm @@ -770,7 +770,7 @@ otherwise simply ignore them." #:reporter (progress-reporter/file (uri-abbreviation uri) size)) (newline))) - #t))) + file))) ((ftp) (false-if-exception* (ftp-fetch uri file #:timeout timeout))) -- 2.16.0
bug#30265: Fish shell has wrong path variables
On Sat, 27 Jan 2018, l...@gnu.org (Ludovic Courtès) wrote: > Hi ng0 and Meiyo, > > n...@n0.is skribis: > >> On Sat, 27 Jan 2018, Meiyo Peng wrote: >>> Hi, >>> >>> I am using GuixSD 0.14. After upgrading fish shell to latest >>> version(v2.7.1) and >>> running `guix gc`, fish shell does not work well. >> >> Can you explain a bit more about your setup? I assume you use >> fish as you user shell and not just as a shell you switch into >> from a Bash enabled user, correct? > > Note that the current ‘guix’ package, 0.14.0-7.33988f9, includes Fish > completion support, which was not the case before: > > --8<---cut here---start->8--- > $ ls -R $(guix build guix)/share/fish > /gnu/store/apji9j8cwf9xpd5jk5mk8s6r1a391yvq-guix-0.14.0-7.33988f9/share/fish: > vendor_completions.d > > /gnu/store/apji9j8cwf9xpd5jk5mk8s6r1a391yvq-guix-0.14.0-7.33988f9/share/fish/vendor_completions.d: > guix.fish > --8<---cut here---end--->8--- > > Could it be the reason why you’re having problems now that you didn’t > experience earlier? > > Any ideas, ng0? > > Thanks, > Ludo’. > > > > No, I'm pretty sure this has nothing to do with adding fish support to Guix. -- ng0 :: https://ea.n0.is A88C8ADD129828D7EAC02E52E22F9BBFEE348588 :: https://ea.n0.is/keys/
