bug#37249: console shell upon login is not ~/.guix-profile/bash -- is this always/never ok?
Bengt Richter writes: > Hello, > > In the pursuit of causes for problems as yet not clear enough to > post as bugs, I am looking for ambivalences in name searches > in /gnu/... and /(the-rest). Hello, I think most guix packages (some won't or require manual configurations) will work on a foreign GNU/Linux distribution, and guix shouldn't cause problems for the distribution. > > The first is immediately bash: > To duplicate, log into a fresh console and look at what's running > and invoked. I did an Alt-F4 and logged in fresh, and captured the > terminal screen seen in the following: > > -8<- > > [ ... snip some output from .bash_profile ... ] > > [13:33 ~/bs]$ ps -o pid,tty,args > PID TT COMMAND > 25500 tty4 -bash > 25966 tty4 ps -o pid,tty,args > [13:35 ~/bs]$ which -a ps > /usr/bin/ps > [13:35 ~/bs]$ file /proc/25500/exe > /proc/25500/exe: symbolic link to /usr/bin/bash > > So, the shell I am talking to right after login is /usr/bin/bash, > but if I type bash, the guix version will be found first: > > [13:36 ~/bs]$ which -a bash > /home/bokr/.guix-profile/bin/bash > /usr/bin/bash > [13:38 ~/bs]$ which -a bash|xargs readlink -f > /gnu/store/qn1ax1fkj16x280m1rv7mcimfmn9l2pf-bash-4.4.23/bin/bash > /usr/bin/bash After login, user's shell program as specified in /etc/passwd will be executed. So you should have '/usr/bin/bash' or '/bin/bash' in /etc/passwd, and your $PATH have '$HOME/.guix-profile/bin' before '/usr/bin', so when type 'bash' in a shell, the guix one got executed. > > So, nesting into the guix one, > > [13:39 ~/bs]$ bash > [13:39 ~/bs]$ ps -o pid,tty,args > PID TT COMMAND > 25500 tty4 -bash > 26226 tty4 bash > 26253 tty4 ps -o pid,tty,args > [13:40 ~/bs]$ file /proc/26226/exe > /proc/26226/exe: symbolic link to > /gnu/store/qn1ax1fkj16x280m1rv7mcimfmn9l2pf-bash-4.4.23/bin/bash > > Indeed our current pid belongs to guix bash. > What is the difference? They were built differently... > > [13:41 ~/bs]$ > [13:42 ~/bs]$ which -a bash > /home/bokr/.guix-profile/bin/bash > /usr/bin/bash > [13:43 ~/bs]$ which -a bash|xargs readlink -f|while read line;do echo -ne > "$line:\n"; file "$line";done > /gnu/store/qn1ax1fkj16x280m1rv7mcimfmn9l2pf-bash-4.4.23/bin/bash: > /gnu/store/qn1ax1fkj16x280m1rv7mcimfmn9l2pf-bash-4.4.23/bin/bash: > ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, > interpreter > > /gnu/store/h90vnqw0nwd0hhm1l5dgxsdrigddfmq4-glibc-2.28/lib/ld-linux-x86-64.so.2, > for GNU/Linux 2.6.32, not stripped > /usr/bin/bash: > /usr/bin/bash: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), > dynamically linked, > interpreter /lib64/ld-linux-x86-64.so.2, > BuildID[sha1]=21a51cb5f7d727370e4d8099d283d7cd20222571, > for GNU/Linux 3.2.0, stripped > > Are the differences possibly dangerous? It's totally OK, you can use both :-) > > The way I got the above, and this tail part itself: > [13:45 ~/bs]$ tty > /dev/tty4 > [13:47 ~/bs]$ su -c 'setterm -file login-bashes.txt -dump 4' > > > Looking for dependencies outside of /gnu from within /gnu, I grepped the whole > as you see below. I am sure most of this is fine and coming out of > documentation > and stuff meant for other than normally booted runtime. But does it all look > ok? > > Or is my foreign-host twilight-zone shared ArchLinux/guix namespace really not > meant to be. I.e., is guix really defined to use /usr/ as a trusted base > namespace > when it is defined by e.g. linux-libre in GuixSD ? > > Where would be the best docs to read about the guix name and environment > rationales? There are no 'namespace' involed, guix and your ArchLinux packages share the same filesystem. And guix binaries are self-contained, they can work without any dependenices outsite of /gnu (sometimes they will use what's available in PATH, etc. which may be provided by your distribution). > > Ok, here is the grep: > (most of the bashes are in the store, as seen at the bottom, but many not) > --- > This was generated by: > grep -Ihr '^ *#!' /gnu|sort|uniq -c|sort -h > gnu-bin-hash-bangs.txt > > 2 #!/bin/csh > 2 #!/bin/tcsh > 2 #!@GAWK@ -f > 2 #!/gnu/store/03n7p9g78ixkrmra674pkx2c9cx8fwmz-guile-1.8.8/bin/guile \ > 2 > #!/gnu/store/0xfmkqpi7xk3ixhrqvjijk4ibsglif62-python-3.7.0/bin/python3.7m > 2 > #!/gnu/store/57daq0hkwvmwx4asiy669cmln868brfm-python2-2.7.15/bin/python2 > 2 #!/gnu/store/9alic3caqhay3h8mx4iihpmyj6ymqpcx-guile-2.2.4/bin/guile > 2 > #!/gnu/store/b7fqhszxl02g6pfm3vw6b3cjz472qrly-python-3.7.0/bin/python3.7m > 2 > #!/gnu/store/cl42c73h609bp2gy92qkh8q56spnnl2n-python-3.7.0/bin/python3.7m > 2 #! /gnu/store/dna8kpb00kq176rz8x69yy4j33my2q55-perl-5.28.0/bin/perl > 2 > #!/gnu/store/h8l1pby3cm6b4fxsfwwr65b4d1hyh6cs-python-3.7.0/bin/python3.7m > 2 #!/gnu/store/l67sib1ld0fgyf0f4vrzyxnmn4yvimvb-gawk
bug#36685: ant-bootstrap fails on core-updates (409 dependents)
I reduced the patch and built openjdk once more to test that it all works. I pushed the changes in a series of commits ending with 6b7e09ae6b to core-updates. -- Ricardo
bug#37332: opam->guix-package test fails
My first post here. I’m assuming the bug number is going to be added
automatically. My apologies in advance, if it’s not.
I’m under GNU Guix SD (a new user), preparing to contribute my first
package. While following [1], I’m getting FAIL for opam->guix-package
after invoking `make check` in the Guix source tree.
The relevant part of the test log:
FAIL: tests/opam
test-name: opam->guix-package
location: /home/w/vurv/guix-git/tests/opam.scm:71
source:
+ (test-assert
+ "opam->guix-package"
+ (mock ((guix import utils)
+ url-fetch
+ (lambda (url file-name)
+(match url
+ ("https://example.org/foo-1.0.0.tar.gz";
+(begin
+ (mkdir-p "foo-1.0.0")
+ (system* "tar" "czvf" file-name "foo-1.0.0/")
+ (delete-file-recursively "foo-1.0.0")
+ (set! test-source-hash
+(call-with-input-file file-name port-sha256
+ (_ (error "Unexpected URL: " url)
+ (let ((my-package
+ (string-append
+ test-repo
+ "/packages/foo/foo.1.0.0")))
+ (mkdir-p my-package)
+ (with-output-to-file
+ (string-append my-package "/opam")
+ (lambda _ (format #t "~a" test-opam-file
+ (mock ((guix import opam)
+get-opam-repository
+(lambda _ test-repo))
+ (match (opam->guix-package "foo")
+ (('package
+('name "ocaml-foo")
+('version "1.0.0")
+('source
+ ('origin
+ ('method 'url-fetch)
+ ('uri "https://example.org/foo-1.0.0.tar.gz";)
+ ('sha256 ('base32 (? string? hash)
+('build-system 'ocaml-build-system)
+('inputs
+ ('quasiquote
+ (("ocaml-zarith" ('unquote 'ocaml-zarith)
+('native-inputs
+ ('quasiquote
+ (("ocaml-alcotest" ('unquote 'ocaml-alcotest))
+ ("ocamlbuild" ('unquote 'ocamlbuild)
+('home-page "https://example.org/";)
+('synopsis "Some example package")
+('description "This package is just an example.")
+('license #f))
+ (string=?
+ (bytevector->nix-base32-string test-source-hash)
+ hash))
+ (x (pk 'fail x #f))
foo-1.0.0/
;;; (fail (package (name "ocaml-foo") (version "1.0.0") (source (origin
(method url-fetch) (uri "https://example.org/foo-1.0.0.tar.gz";) (sha256 (base32
"1krpnm4j5f8xi2h6jaq3v97alv9dz7v2mdw53a8sycw4i97qxkaq" (build-system
ocaml-build-system) (propagated-inputs (quasiquote (("ocaml-zarith" (unquote
ocaml-zarith) (native-inputs (quasiquote (("ocaml-alcotest" (unquote
ocaml-alcotest)) ("ocamlbuild" (unquote ocamlbuild) (home-page
"https://example.org/";) (synopsis "Some example package") (description "This
package is just an example.") (license #f)) #f)
actual-value: #f
result: FAIL
Software versions:
GNU Guix: 66d2133 for invoking `guix environment`, d550845 for the
tested source tree
GNU Guile: 2.2.4
Guile-Gcrypt: 0.1.0
GnuTLS: 3.6.5
Guile-SQLite3: 0.1.0
Guile-Git: 0.2.0
Guile-JSON: 1.2.0
zlib: 1.2.11
GNU Make: 4.2.1
In the mailing list archives, I can see some recurring opam/ocaml
issues, but I’m not familiar with any of those, so I cannot judge what
the problem could be. I will appreciate any hints.
WŻ
[1]: https://guix.gnu.org/manual/en/html_node/Building-from-Git.html
signature.asc
Description: PGP signature
bug#37332: opam->guix-package test fails
Le 7 septembre 2019 12:22:00 GMT+02:00, "Wiktor Żelazny" a
écrit :
>My first post here. I’m assuming the bug number is going to be added
>automatically. My apologies in advance, if it’s not.
>
>I’m under GNU Guix SD (a new user), preparing to contribute my first
>package. While following [1], I’m getting FAIL for opam->guix-package
>after invoking `make check` in the Guix source tree.
>
>The relevant part of the test log:
>
> FAIL: tests/opam
>
>
> test-name: opam->guix-package
> location: /home/w/vurv/guix-git/tests/opam.scm:71
> source:
> + (test-assert
> + "opam->guix-package"
> + (mock ((guix import utils)
> + url-fetch
> + (lambda (url file-name)
> +(match url
> + ("https://example.org/foo-1.0.0.tar.gz";
> +(begin
> + (mkdir-p "foo-1.0.0")
> + (system* "tar" "czvf" file-name "foo-1.0.0/")
> + (delete-file-recursively "foo-1.0.0")
> + (set! test-source-hash
>+(call-with-input-file file-name
>port-sha256
> + (_ (error "Unexpected URL: " url)
> + (let ((my-package
> + (string-append
> + test-repo
> + "/packages/foo/foo.1.0.0")))
> + (mkdir-p my-package)
> + (with-output-to-file
> + (string-append my-package "/opam")
> + (lambda _ (format #t "~a" test-opam-file
> + (mock ((guix import opam)
> +get-opam-repository
> +(lambda _ test-repo))
> + (match (opam->guix-package "foo")
> + (('package
> +('name "ocaml-foo")
> +('version "1.0.0")
> +('source
> + ('origin
> + ('method 'url-fetch)
>+ ('uri
>"https://example.org/foo-1.0.0.tar.gz";)
> + ('sha256 ('base32 (? string? hash)
> +('build-system 'ocaml-build-system)
> +('inputs
> + ('quasiquote
>+ (("ocaml-zarith" ('unquote
>'ocaml-zarith)
> +('native-inputs
> + ('quasiquote
>+ (("ocaml-alcotest" ('unquote
>'ocaml-alcotest))
> + ("ocamlbuild" ('unquote 'ocamlbuild)
> +('home-page "https://example.org/";)
> +('synopsis "Some example package")
>+('description "This package is just an
>example.")
> +('license #f))
> + (string=?
>+ (bytevector->nix-base32-string
>test-source-hash)
> + hash))
> + (x (pk 'fail x #f))
> foo-1.0.0/
>
>;;; (fail (package (name "ocaml-foo") (version "1.0.0") (source (origin
>(method url-fetch) (uri "https://example.org/foo-1.0.0.tar.gz";) (sha256
>(base32 "1krpnm4j5f8xi2h6jaq3v97alv9dz7v2mdw53a8sycw4i97qxkaq"
>(build-system ocaml-build-system) (propagated-inputs (quasiquote
>(("ocaml-zarith" (unquote ocaml-zarith) (native-inputs (quasiquote
>(("ocaml-alcotest" (unquote ocaml-alcotest)) ("ocamlbuild" (unquote
>ocamlbuild) (home-page "https://example.org/";) (synopsis "Some
>example package") (description "This package is just an example.")
>(license #f)) #f)
> actual-value: #f
> result: FAIL
>
>Software versions:
>
> GNU Guix: 66d2133 for invoking `guix environment`, d550845 for the
> tested source tree
> GNU Guile: 2.2.4
> Guile-Gcrypt: 0.1.0
> GnuTLS: 3.6.5
> Guile-SQLite3: 0.1.0
> Guile-Git: 0.2.0
> Guile-JSON: 1.2.0
> zlib: 1.2.11
> GNU Make: 4.2.1
>
>In the mailing list archives, I can see some recurring opam/ocaml
>issues, but I’m not familiar with any of those, so I cannot judge what
>the problem could be. I will appreciate any hints.
>
>WŻ
>
>[1]: https://guix.gnu.org/manual/en/html_node/Building-from-Git.html
Thanks for the report! I recently changed the importer to use propagated inputs
instead of inputs and forgot about the test. I just pushed 1d03a91 which fixes
the test.
bug#37309: ‘ssh-daemon’ service fails to start at boot
Giovanni Biscuolo writes: > Hi, > > following a recent discussion on guix-sysadmin I have to confirm the > ssh-daemon issue since it is still happening on some of the machines I > administer > > Previous possibly related bug reports are > https://issues.guix.gnu.org/issue/30993 and > https://issues.guix.gnu.org/issue/32197 > > Unfortunately this issue is *not* well reproducible, it depends on some > mysterious (to me) timing factor; AFAIU it does *not* depend on the > shepherd version, probably it depends on "something" related to IPv6 > (read below the details) Hello, thank you for this report, it's reproducible with my box that has an old hard disk, and disable IPv6 for sshd does fix the issue for me... > > Andreas Enge writes: > > [...] > >> My impression is that the problem is still there. I am quite certain it >> happened when I rebooted dover, since I had to connect on the serial console >> to manually restart the ssh service. > > I'm sure it happened when milano-guix-1 was rebooted due to data centre > maintenance and happened yesterday to one of my personal Guix machines at > office > > [...] > > My situation is similar to the one observed by Andreas > >> Well, it is in /var/log/messages: >> Aug 3 21:11:38 localhost sshd[360]: Server listening on 0.0.0.0 port 22. >> Aug 3 21:11:55 localhost shepherd[1]: Service ssh-daemon could not be >> started. > > [...] > Sep 4 21:46:02 localhost shepherd[1]: Service syslogd has been started. > [...] > Sep 4 21:46:03 localhost shepherd[1]: Service loopback has been started. > [...] > Sep 4 21:46:22 localhost vmunix: [0.226337] PCI: Using configuration > type 1 for base access > Sep 4 21:46:09 localhost dhclient: DHCPREQUEST for 10.38.2.16 on eno1 to > 255.255.255.255 port 67 > [...] > Sep 4 21:46:24 localhost shepherd[1]: Service networking has been started. > [...] > Sep 4 21:46:12 localhost sshd[577]: Server listening on 0.0.0.0 port 22. > [...] > Sep 4 21:46:30 localhost vmunix: [0.250107] ACPI: PCI Interrupt Link > [LNKA] (IRQs 3 4 5 6 10 *11 12 14 15) > Sep 4 21:46:13 localhost dhclient: DHCPREQUEST for 10.38.2.16 on eno1 to > 255.255.255.255 port 67 > [...] > Sep 4 21:46:16 localhost dhclient: DHCPACK of 10.38.2.16 from 10.38.2.1 > [...] > Sep 4 21:46:33 localhost shepherd[1]: Service ssh-daemon could not be > started. > [...] > Sep 4 21:46:47 localhost vmunix: [0.731142] Segment Routing with IPv6 > > > Please note the timing of the dhclient and the sshd processes: I > inserted them as printed in /var/log/messages but they are not > time-sequential: does it means something or is irrelevant? > > So the sshd process started (as far as I cen see there is no trace it > was stopped) and pretty soon shepherd noticed ssh-daemon was not > started. > > Logging in from the console I see the ssh-daemon is stopped but enabled: > > Status of ssh-daemon: > It is stopped. > It is enabled. > Provides (ssh-daemon). > Requires (syslogd loopback). > Conflicts with (). > Will be respawned. > > > [...] Yes, I think when 'ssh-daemon' failed to start, shepherd should respawn it until success or disable it, but by look at the code of 'make-forkexec-constructor', when using 'pid-file' (as 'ssh-ademon' does), and a timeout (default to 5s %pid-file-timeout) is reached, the processes got a 'SIGTERM' and return '#f' as its running state, which won't be respawn (it's not a pid number) I guess... To ludo: Is my analysis correct? It's not clear to me how to fix it so 'ssh-daemon' can be respawn though... > > If I start it via `sudo herd start ssh-daemon` it immediatly starts, > like in Andreas experience: > >> Aug 3 21:13:10 localhost sshd[385]: Server listening on 0.0.0.0 port 22. >> Aug 3 21:13:10 localhost sshd[385]: Server listening on :: port 22. >> Aug 3 21:13:11 localhost shepherd[1]: Service ssh-daemon has been started. > > Sep 5 13:38:55 localhost sshd[745]: Server listening on 0.0.0.0 port 22. > Sep 5 13:38:55 localhost sshd[745]: Server listening on :: port 22. > Sep 5 13:38:55 localhost shepherd[1]: Service ssh-daemon has been started. > > > Please notice the difference from above: this time the sshd server is > also listening on the IPv6 address :: while in the above log it was only > listening on the 0.0.0.0 IPv4 address > > Does the failure have something to do with IPv6 not available when sshd > starts for the first time after a reboot? I agree, as adding '(extra-content "ListenAddress 0.0.0.0")' to my 'openssh-configuration' to skip the ipv6 listen fix this issue for me. A proper fix should be respawn 'ssh-daemon' and start it after 'ipv6 available' (i don't know what this mean yet..).
