bug#39970: guix commands broken on Azerbaijani 'az_AZ' and Turkish 'tr_TR' locales
"pelzflorian (Florian Pelz)" skribis: > On Tue, Mar 17, 2020 at 10:20:01PM +0100, Ludovic Courtès wrote: >> "pelzflorian (Florian Pelz)" skribis: >> > `LC_ALL=tr_TR.utf8 make check` is still very unhappy though. >> > There are many failures. I will continue to investigate later today. >> >> OK. > > The tests fail to many other uses of [a-z] in regexps. I will look; > for e.g. guix/import/cran.scm > > (if (string-match "^[A-Za-z][^ :]+:( |\n|$)" line) > …) > > it would be easier and clearer to just list [a-z] explicitly: Yes, agreed. It would be nice if ‘string-match’ & co. could take an optional locale object (info "(guile) i18n Introduction") but that’s not the case currently. Thanks, Ludo’.
bug#37237: mcron randomly stops running jobs
Hi, Robert Vollmert skribis: > I have numerous mcron jobs configured, many of which run every 15 minutes, > and one which runs once a minute. Just now, at 19:22, I noticed the minutely > cron job didn’t seem to run, and saw that one every-15-minute job which always > logs to mcron.log had last run at 18:00. I restarted mcron, and jobs started > running again. There is no timezone confusion either: That every-15-minute job > logged its first run at 19:30. When mcron is stuck, it’s apparently stuck in ‘pthread_join’, waiting for the finalization thread to terminate: --8<---cut here---start->8--- (gdb) bt #0 0x7f7f730d8478 in __GI___pthread_timedjoin_ex (threadid=140185229293312, thread_return=thread_return@entry=0x0, abstime=abstime@entry=0x0, block=block@entry=true) at pthread_join_common.c:84 #1 0x7f7f730d82dc in __pthread_join (threadid=, thread_return=thread_return@entry=0x0) at pthread_join.c:24 #2 0x7f7f731d7508 in stop_finalization_thread () at finalizers.c:265 #3 0x7f7f731d7729 in scm_i_finalizer_pre_fork () at finalizers.c:290 #4 0x7f7f73250426 in scm_fork () at posix.c:1220 #5 0x7f7f7324979f in vm_regular_engine (thread=0x7f7f6acb79d0, vp=0x7f7f6b299f30, registers=0xafaf, resume=1930265720) at vm-engine.c:786 #6 0x7f7f7324bfd7 in scm_call_n (proc=#, argv=argv@entry=0x7ffd9b10bed8, nargs=nargs@entry=1) at vm.c:1260 #7 0x7f7f731cdf58 in scm_call_1 (proc=, arg1=) at eval.c:485 #8 0x0040130c in inner_main () #9 0x7f7f731e5cfd in invoke_main_func (body_data=0x7ffd9b10c3b0) at init.c:341 #10 0x7f7f731c835a in c_body (d=0x7ffd9b10c2f0) at continuations.c:422 #11 0x7f7f7324979f in vm_regular_engine (thread=0x7f7f6acb79d0, vp=0x7f7f6b299f30, registers=0xafaf, resume=1930265720) at vm-engine.c:786 #12 0x7f7f7324bfd7 in scm_call_n (proc=proc@entry=#, argv=argv@entry=0x0, nargs=nargs@entry=0) at vm.c:1260 #13 0x7f7f731cdf39 in scm_call_0 (proc=proc@entry=#) at eval.c:479 #14 0x7f7f7323ac12 in catch (tag=tag@entry=#t, thunk=#, handler=0x7f7f6b2a1420, pre_unwind_handler=0x7f7f6b2a1400) at throw.c:137 #15 0x7f7f7323aef5 in scm_catch_with_pre_unwind_handler (key=key@entry=#t, thunk=, handler=, pre_unwind_handler=) at throw.c:254 #16 0x7f7f7323b0bf in scm_c_catch (tag=tag@entry=#t, body=body@entry=0x7f7f731c8350 , body_data=body_data@entry=0x7ffd9b10c2f0, handler=handler@entry=0x7f7f731c85e0 , handler_data=handler_data@entry=0x7ffd9b10c2f0, pre_unwind_handler=pre_unwind_handler@entry=0x7f7f731c8440 , pre_unwind_handler_data=0x7f7f6b2939a0) at throw.c:377 #17 0x7f7f731c8940 in scm_i_with_continuation_barrier (body=body@entry=0x7f7f731c8350 , body_data=body_data@entry=0x7ffd9b10c2f0, handler=handler@entry=0x7f7f731c85e0 , handler_data=handler_data@entry=0x7ffd9b10c2f0, pre_unwind_handler=pre_unwind_handler@entry=0x7f7f731c8440 , pre_unwind_handler_data=0x7f7f6b2939a0) at continuations.c:360 #18 0x7f7f731c89d5 in scm_c_with_continuation_barrier (func=, data=) at continuations.c:456 #19 0x7f7f7323984c in with_guile (base=base@entry=0x7ffd9b10c358, data=data@entry=0x7ffd9b10c380) at threads.c:661 #20 0x7f7f73127a68 in GC_call_with_stack_base (fn=fn@entry=0x7f7f73239800 , arg=arg@entry=0x7ffd9b10c380) at misc.c:1941 #21 0x7f7f73239b68 in scm_i_with_guile (dynamic_state=, data=data@entry=0x7ffd9b10c380, func=func@entry=0x7f7f731e5ce0 ) at threads.c:704 #22 scm_with_guile (func=func@entry=0x7f7f731e5ce0 , data=data@entry=0x7ffd9b10c3b0) at threads.c:710 #23 0x7f7f731e5e92 in scm_boot_guile (argc=12, argv=0x7ffd9b10c4f8, main_func=0x4012a0 , closure=0x0) at init.c:324 #24 0x0040118b in main () --8<---cut here---end--->8--- The finalization thread lives its life as if it hadn’t received the “stop” message in its pipe: --8<---cut here---start->8--- (gdb) thread 17 [Switching to thread 17 (Thread 0x7f7f6acb7700 (LWP 44975))] #0 0x7f7f730e0344 in __libc_read (fd=5, buf=buf@entry=0x7f7f6acb6a40, nbytes=nbytes@entry=1) at ../sysdeps/unix/sysv/linux/read.c:26 26 ../sysdeps/unix/sysv/linux/read.c: No such file or directory. (gdb) bt #0 0x7f7f730e0344 in __libc_read (fd=5, buf=buf@entry=0x7f7f6acb6a40, nbytes=nbytes@entry=1) at ../sysdeps/unix/sysv/linux/read.c:26 #1 0x7f7f731d7497 in read_finalization_pipe_data (data=0x7f7f6acb6a40) at finalizers.c:199 #2 0x7f7f7312d503 in GC_do_blocking_inner (data=0x7f7f6acb6a00 "\200t\035s\177\177", context=) at pthread_support.c:1362 #3 0x7f7f73121d62 in GC_with_callee_saves_pushed (fn=0x7f7f7312d4c0 , arg=arg@entry=0x7f7f6acb6a00 "\200t\035s\177\177") at mach_dep.c:328 #4 0x7f7f73127a9c in GC_do_blocking (fn=fn@entry=0x7f7f731d7480 , client_data=client_data@entry=0x7f7f6acb6a40) at misc.c:2053 #5 0x7f7f73239bba in scm_without_guile (func=0x7f7f731d7480 , d
bug#40116: GDM: Memory leak in .gnome-shell-real process
I can't use GNOME anymore because of the problem I explained in the following thread: https://lists.gnu.org/archive/html/help-guix/2020-02/msg00206.html On recent system upgrades, the problem got worse. Before, I could get to the end of the day despite the leak; but now it takes around 3 hours for the .gnome-shell-real process run by the gdm user to eat the remaining RAM. It seems that the bug is stronger in the GNOME desktop, but I've seen, at least once, .gnome-shell-real using an abnormal amount of RAM while in sway (about 800 MiB). My current guix: $ guix describe Generation 61 Mar 15 2020 08:44:39(current) sirgazil-x 8274cd7 repository URL: https://gitlab.com/sirgazil/guix-channel-x.git branch: master commit: 8274cd78f9f6d58e00e057a0eabe58e4e143cc4d guix a431a63 repository URL: https://git.savannah.gnu.org/git/guix.git branch: master commit: a431a63537c8103b2a58c9a55d90184fb5c90361 --- https://sirgazil.bitbucket.io/
bug#40116: GDM: Memory leak in .gnome-shell-real process
Hi sirgazil, sirgazil via Bug reports for GNU Guix skribis: > I can't use GNOME anymore because of the problem I explained in the following > thread: > > https://lists.gnu.org/archive/html/help-guix/2020-02/msg00206.html > > On recent system upgrades, the problem got worse. Before, I could get to the > end of the day despite the leak; but now it takes around 3 hours for the > .gnome-shell-real process run by the gdm user to eat the remaining RAM. Ouch. > It seems that the bug is stronger in the GNOME desktop, but I've seen, at > least once, .gnome-shell-real using an abnormal amount of RAM while in sway > (about 800 MiB). Could you check if it happens in a VM? That is, you build your GNOME config with ‘guix system vm’, try to do some activity in the VM, and check in top whether ‘gnome-shell’ is growing. Thanks, Ludo’.
bug#40116: GDM: Memory leak in .gnome-shell-real process
Le 18 mars 2020 10:18:11 GMT-04:00, sirgazil via Bug reports for GNU Guix a écrit : >I can't use GNOME anymore because of the problem I explained in the >following thread: > >https://lists.gnu.org/archive/html/help-guix/2020-02/msg00206.html > >On recent system upgrades, the problem got worse. Before, I could get >to the end of the day despite the leak; but now it takes around 3 hours >for the .gnome-shell-real process run by the gdm user to eat the >remaining RAM. > >It seems that the bug is stronger in the GNOME desktop, but I've seen, >at least once, .gnome-shell-real using an abnormal amount of RAM while >in sway (about 800 MiB). > >My current guix: > >$ guix describe >Generation 61 Mar 15 2020 08:44:39(current) > sirgazil-x 8274cd7 >repository URL: https://gitlab.com/sirgazil/guix-channel-x.git >branch: master >commit: 8274cd78f9f6d58e00e057a0eabe58e4e143cc4d > guix a431a63 >repository URL: https://git.savannah.gnu.org/git/guix.git >branch: master >commit: a431a63537c8103b2a58c9a55d90184fb5c90361 > > >--- >https://sirgazil.bitbucket.io/ I'm also hit by that bug. I do not use gnome though, and the .gnome-session-real process is owned by gdm. Ram usage is at around 200MB when starting and after a few days (putting the laptop to sleep during the night), it got to 2.4GB, even though I don't really need or use it beside logging in. After another restart, it was at 600MB after a day. That memory usage is ridiculous :/
bug#40116: GDM: Memory leak in .gnome-shell-real process
On Wed, 18 Mar 2020 10:09:57 -0500 Ludovic Courtès wrote [...] > > It seems that the bug is stronger in the GNOME desktop, but I've seen, at > > least once, .gnome-shell-real using an abnormal amount of RAM while in > > sway (about 800 MiB). > > Could you check if it happens in a VM? That is, you build your GNOME > config with ‘guix system vm’, try to do some activity in the VM, and > check in top whether ‘gnome-shell’ is growing. I can try, but last time I did something like that the VM with GNOME was too slow to do anything (this computer only has 4 GiB of RAM).
bug#40123: glibc-locales: links missing in root user profile
To reproduce the bug: * install guix on top of an ordinary linux distribution using the install script at guix.gnu.org * install glibc-locales as root Expected: There should be a link ~root/.guix-profile/lib/locales Actual: No such link has been installed. Note: The link does get installed for other users than root.
bug#36402: installation error
Hello, This has hopefully been resolved by Guile-Parted 0.0.2 update, so closing! Thanks, Mathieu
bug#35543: Installer crashes on retry when selecting keyboard layout
Hello, This has been fixed by 64704be417ab6f2788e8e3bc36fede1db35470e7. Thanks, Mathieu
bug#35543: Installer crashes on retry when selecting keyboard layout
and done. Mathieu
bug#35690: Fixed
This has been fixed by 64704be417ab6f2788e8e3bc36fede1db35470e7. Thanks, Mathieu
bug#35700: Fixed
This has been fixed by 64704be417ab6f2788e8e3bc36fede1db35470e7. Thanks, Mathieu
bug#40123: glibc-locales: links missing in root user profile
Tje Mikael, Mikael Djurfeldt writes: > To reproduce the bug: > > * install guix on top of an ordinary linux distribution using the install > script at guix.gnu.org > > * install glibc-locales as root > > Expected: > > There should be a link ~root/.guix-profile/lib/locales That should be ~root/.guix-profile/lib/locale (note the singular). This directory actually comes pre-populated with a small subset of UTF-8 locales when using the binary installation method like the script does, so it's odd if you don't find anything there. Which distribution are you on, and how do you become root? Is the $HOME variable set to root's home directory when you are in a root shell? To figure out where the package gets installed, try running this command: find /var/guix/profiles -name sv_SE.utf8 -type d signature.asc Description: PGP signature
bug#40123: glibc-locales: links missing in root user profile
On Wed, Mar 18, 2020 at 7:18 PM Marius Bakke wrote: > Tje Mikael, > > Mikael Djurfeldt writes: > > > To reproduce the bug: > > > > * install guix on top of an ordinary linux distribution using the install > > script at guix.gnu.org > > > > * install glibc-locales as root > > > > Expected: > > > > There should be a link ~root/.guix-profile/lib/locales > > That should be ~root/.guix-profile/lib/locale (note the singular). > Right (just misspelled in the bug report). > This directory actually comes pre-populated with a small subset of UTF-8 > locales when using the binary installation method like the script does, > so it's odd if you don't find anything there. > I think so too. (But it's not true that it is a small subset of UTF-8 locales. It's a big package with several types of locale.) > > Which distribution are you on, Debian Buster > and how do you become root? sudo -i > Is the $HOME > variable set to root's home directory when you are in a root shell? > Yes. To figure out where the package gets installed, try running this > command: > > find /var/guix/profiles -name sv_SE.utf8 -type d > It's obvious that that line will produce an empty result. That is because the sv_SE.utf8 directory only exists in the store. But I don't see the point of looking it up in the store. The problem is that the link into the store from the root user profile is never created. (It *is* created in other user profiles.) Best regards, Mikael
bug#40123: glibc-locales: links missing in root user profile
Mikael Djurfeldt writes: > To figure out where the package gets installed, try running this >> command: >> >> find /var/guix/profiles -name sv_SE.utf8 -type d >> > > It's obvious that that line will produce an empty result. That is because > the sv_SE.utf8 directory only exists in the store. But I don't see the > point of looking it up in the store. The problem is that the link into the > store from the root user profile is never created. (It *is* created in > other user profiles.) I suspected that Guix installed it to a different user profile somehow, since you did not get any errors apart from the missing directory (if I read the bug report correctly). Does 'guix install hello' work? signature.asc Description: PGP signature
bug#40123: glibc-locales: links missing in root user profile
On Wed, Mar 18, 2020 at 7:40 PM Marius Bakke wrote: > Mikael Djurfeldt writes: > > > To figure out where the package gets installed, try running this > >> command: > >> > >> find /var/guix/profiles -name sv_SE.utf8 -type d > >> > > > > It's obvious that that line will produce an empty result. That is because > > the sv_SE.utf8 directory only exists in the store. But I don't see the > > point of looking it up in the store. The problem is that the link into > the > > store from the root user profile is never created. (It *is* created in > > other user profiles.) > > I suspected that Guix installed it to a different user profile somehow, > since you did not get any errors apart from the missing directory (if I > read the bug report correctly). > > Does 'guix install hello' work? > Same problem there. But thank you for your hypothesis above! I tried a different line with ls -lLR and grep and then discovered that the links *are* indeed installed in a different profile. This led me to find my problem: For some reason, my ~root/.guix-profile was pointing to the current-guix profile rather than the guix-profile. It could have been me who did that. :( Anyway, problem solved! This was not a guix bug. Best regards, Mikael
bug#40123: glibc-locales: links missing in root user profile
Mikael Djurfeldt writes: > On Wed, Mar 18, 2020 at 7:40 PM Marius Bakke wrote: > >> Mikael Djurfeldt writes: >> >> > To figure out where the package gets installed, try running this >> >> command: >> >> >> >> find /var/guix/profiles -name sv_SE.utf8 -type d >> >> >> > >> > It's obvious that that line will produce an empty result. That is because >> > the sv_SE.utf8 directory only exists in the store. But I don't see the >> > point of looking it up in the store. The problem is that the link into >> the >> > store from the root user profile is never created. (It *is* created in >> > other user profiles.) >> >> I suspected that Guix installed it to a different user profile somehow, >> since you did not get any errors apart from the missing directory (if I >> read the bug report correctly). >> >> Does 'guix install hello' work? >> > > Same problem there. > > But thank you for your hypothesis above! I tried a different line with ls > -lLR and grep and then discovered that the links *are* indeed installed in > a different profile. > > This led me to find my problem: For some reason, my ~root/.guix-profile was > pointing to the current-guix profile rather than the guix-profile. > > It could have been me who did that. :( Heh, at least you got a decent learning experience. ;-) > Anyway, problem solved! This was not a guix bug. Awesome, glad you found the problem! I'm closing the bug report. signature.asc Description: PGP signature
bug#40125: Problem with guix offload: Remote channel closed
Hi,
I just installed guix on top of Debian Buster using the installation script
at guix.gnu.org. I did this on two machines, hat and wand, with the hope
that I could offload compilation to wand.
This is what I get:
root@hat:~# guix offload test
guile: warning: failed to install locale
hint: Consider installing the `glibc-utf8-locales' or `glibc-locales'
package and
defining `GUIX_LOCPATH', along these lines:
guix package -i glibc-utf8-locales
export GUIX_LOCPATH="$HOME/.guix-profile/lib/locale"
See the "Application Setup" section in the manual, for more info.
guix offload: testing 1 build machines defined in
'/etc/guix/machines.scm'...
guix offload: Guix is usable on 'wand.pdc.kth.se' (test returned
"/gnu/store/883yjkl46dxw9mzykykmbs0yzwyxm17z-test")
guix offload: 'wand.pdc.kth.se' is running GNU Guile 3.0.1
sending 1 store item (0 MiB) to 'wand.pdc.kth.se'...
exporting path `/gnu/store/sd0wqvaffi1cbpvf0dq37mab34rmlnav-export-test'
;;; [2020/03/17 12:45:48.671038, 0] write_to_channel_port: [GSSH ERROR]
Remote channel is closed: #
Backtrace:
1 (primitive-load "/root/.config/guix/current/bin/guix")
In guix/ui.scm:
1833:12 0 (run-guix-command _ . _)
guix/ui.scm:1833:12: In procedure run-guix-command:
Throw to key `guile-ssh-error' with args `("write_to_channel_port" "Remote
channel is closed" # #f)'.
Any hints about what could be wrong?
Best regards,
Mikael Djurfeldt
bug#40125: Problem with guix offload: Remote channel closed
This is a more up-to-date log where a problem in my environment (both on
local and build host) was fixed:
mdj@hat:~$ guix offload test
guix offload: testing 1 build machines defined in
'/etc/guix/machines.scm'...
guix offload: Guix is usable on 'wand.pdc.kth.se' (test returned
"/gnu/store/883yjkl46dxw9mzykykmbs0yzwyxm17z-test")
guix offload: 'wand.pdc.kth.se' is running GNU Guile 3.0.1
sending 1 store item (0 MiB) to 'wand.pdc.kth.se'...
exporting path `/gnu/store/gl7dps3yx0vrxz16sj7q3w7gs3vdbxj4-export-test'
;;; [2020/03/18 20:53:04.930901, 0] write_to_channel_port: [GSSH ERROR]
Remote channel is closed: #
Backtrace:
1 (primitive-load "/home/mdj/.config/guix/current/bin/guix")
In guix/ui.scm:
1833:12 0 (run-guix-command _ . _)
guix/ui.scm:1833:12: In procedure run-guix-command:
Throw to key `guile-ssh-error' with args `("write_to_channel_port" "Remote
channel is closed" # #f)'.
bug#35519: guix master 4de63cf3fc0a831d75cb507456821104f24800c2: rust 1.19.0 build failure on i686-linux
Hi, so after our mrustc upgrade to 0.9, we get the following when building rust 1.19.0 on guix master 4de63cf3fc0a831d75cb507456821104f24800c2 and i686-linux: [...] (75/77) BUILDING git2_curl from git2-curl v0.7.0 > /gnu/store/0hzdzb07gaplh2x96mg7dpvip92shx43-mrustc-0.9/bin/mrustc > src/vendor/git2-curl/src/lib.rs -o output/cargo-build/libgit2_curl-0_7_0.rlib > --crate-name git2_curl --crate-type rlib -C > emit-depfile=output/cargo-build/libgit2_curl-0_7_0.rlib.d --crate-tag 0_7_0 > -g --cfg debug_assertions -O -L output -L > /gnu/store/0hzdzb07gaplh2x96mg7dpvip92shx43-mrustc-0.9/lib/mrust -L > output/cargo-build --extern curl=output/cargo-build/libcurl-0_4_6.rlib > --extern url=output/cargo-build/liburl-1_4_0.rlib --extern > log=output/cargo-build/liblog-0_3_7.rlib --extern > git2=output/cargo-build/libgit2-0_6_6.rlib (76/77) BUILDING cargo v0.20.0 > /gnu/store/0hzdzb07gaplh2x96mg7dpvip92shx43-mrustc-0.9/bin/mrustc > src/tools/cargo/src/cargo/lib.rs -o output/cargo-build/libcargo-0_20_0.rlib > --crate-name cargo --crate-type rlib -C > emit-depfile=output/cargo-build/libcargo-0_20_0.rlib.d --crate-tag 0_20_0 -g > --cfg debug_assertions -O -L output -L > /gnu/store/0hzdzb07gaplh2x96mg7dpvip92shx43-mrustc-0.9/lib/mrust -L > output/cargo-build --extern > crates_io=output/cargo-build/libcrates_io-0_9_0.rlib --extern > crossbeam=output/cargo-build/libcrossbeam-0_2_10.rlib --extern > curl=output/cargo-build/libcurl-0_4_6.rlib --extern > docopt=output/cargo-build/libdocopt-0_7_0.rlib --extern > env_logger=output/cargo-build/libenv_logger-0_4_2.rlib --extern > error_chain=output/cargo-build/liberror_chain-0_10_0.rlib --extern > filetime=output/cargo-build/libfiletime-0_1_10.rlib --extern > flate2=output/cargo-build/libflate2-0_2_19.rlib --extern > fs2=output/cargo-build/libfs2-0_4_1.rlib --extern > git2=output/cargo-build/libgit2-0_6_6.rlib --extern > git2_curl=output/cargo-build/libgit2_curl-0_7_0.rlib --extern > glob=output/cargo-build/libglob-0_2_11.rlib --extern > jobserver=output/cargo-build/libjobserver-0_1_6.rlib --extern > libc=output/cargo-build/liblibc-0_2_22.rlib --extern > libgit2_sys=output/cargo-build/liblibgit2_sys-0_6_12.rlib --extern > log=output/cargo-build/liblog-0_3_7.rlib --extern > num_cpus=output/cargo-build/libnum_cpus-1_4_0.rlib --extern > rustc_serialize=output/cargo-build/librustc_serialize-0_3_24.rlib --extern > scoped_tls=output/cargo-build/libscoped_tls-0_1_0.rlib --extern > semver=output/cargo-build/libsemver-0_7_0.rlib --extern > serde=output/cargo-build/libserde-1_0_6.rlib --extern > serde_derive=output/cargo-build/libserde_derive-1_0_6-plugin --extern > serde_ignored=output/cargo-build/libserde_ignored-0_0_3.rlib --extern > serde_json=output/cargo-build/libserde_json-1_0_2.rlib --extern > shell_escape=output/cargo-build/libshell_escape-0_1_3.rlib --extern > tar=output/cargo-build/libtar-0_4_13.rlib --extern > tempdir=output/cargo-build/libtempdir-0_3_5.rlib --extern > term=output/cargo-build/libterm-0_4_5.rlib --extern > toml=output/cargo-build/libtoml-0_4_1.rlib --extern > url=output/cargo-build/liburl-1_4_0.rlib --extern > openssl=output/cargo-build/libopenssl-0_9_12.rlib BUILDING cargo v0.20.0 > /gnu/store/0hzdzb07gaplh2x96mg7dpvip92shx43-mrustc-0.9/bin/mrustc > src/tools/cargo/src/bin/cargo.rs -o output/cargo-build/cargo --crate-name > cargo --crate-type bin -C emit-depfile=output/cargo-build/cargo.d --crate-tag > 0_20_0 -g --cfg debug_assertions -O -L output -L > /gnu/store/0hzdzb07gaplh2x96mg7dpvip92shx43-mrustc-0.9/lib/mrust -L > output/cargo-build --extern cargo=output/cargo-build/libcargo-0_20_0.rlib > --extern crates_io=output/cargo-build/libcrates_io-0_9_0.rlib --extern > crossbeam=output/cargo-build/libcrossbeam-0_2_10.rlib --extern > curl=output/cargo-build/libcurl-0_4_6.rlib --extern > docopt=output/cargo-build/libdocopt-0_7_0.rlib --extern > env_logger=output/cargo-build/libenv_logger-0_4_2.rlib --extern > error_chain=output/cargo-build/liberror_chain-0_10_0.rlib --extern > filetime=output/cargo-build/libfiletime-0_1_10.rlib --extern > flate2=output/cargo-build/libflate2-0_2_19.rlib --extern > fs2=output/cargo-build/libfs2-0_4_1.rlib --extern > git2=output/cargo-build/libgit2-0_6_6.rlib --extern > git2_curl=output/cargo-build/libgit2_curl-0_7_0.rlib --extern > glob=output/cargo-build/libglob-0_2_11.rlib --extern > jobserver=output/cargo-build/libjobserver-0_1_6.rlib --extern > libc=output/cargo-build/liblibc-0_2_22.rlib --extern > libgit2_sys=output/cargo-build/liblibgit2_sys-0_6_12.rlib --extern > log=output/cargo-build/liblog-0_3_7.rlib --extern > num_cpus=output/cargo-build/libnum_cpus-1_4_0.rlib --extern > rustc_serialize=output/cargo-build/librustc_serialize-0_3_24.rlib --extern > scoped_tls=output/cargo-build/libscoped_tls-0_1_0.rlib --extern > semver=output/cargo-build/libsemver-0_7_0.rlib --extern > serde=output/cargo-build/libserde-1_0_6.rlib --extern > serde_derive=output/cargo-bui
bug#40123: glibc-locales: links missing in root user profile
On 2020-03-18 20:02, Mikael Djurfeldt wrote: On Wed, Mar 18, 2020 at 7:40 PM Marius Bakke wrote: Mikael Djurfeldt writes: To figure out where the package gets installed, try running this command: find /var/guix/profiles -name sv_SE.utf8 -type d It's obvious that that line will producethere. But thank you for your hypothesis above! I tried a different line with ls -lLR and grep and then discovered that the links *are* indeed installed in a different profile. This led me to find my problem: For some rea an empty result. That is because the sv_SE.utf8 directory only exists in the store. But I don't see the point of looking it up in the store. The problem is that the link into the store from the root user profile is never created. (It *is* created in other user profiles.) I suspected that Guix installed it to a different user profile somehow, since you did not get any errors apart from the missing directory (if I read the bug report correctly). Does 'guix install hello' work? Same problem there. But thank you for your hypothesis above! I tried a different line with ls -lLR and grep and then discovered that the links *are* indeed installed in a different profile. This led me to find my problem: For some reason, my ~root/.guix-profile was pointing to the current-guix profile rather than the guix-profile. It could have been me who did that. :( Anyway, problem solved! This was not a guix bug. Not so fast! I just did the same yesterday using the install-script but on a RedHat server, and my /root/.config/guix/current pointed at /var/guix/profiles/per-user/MYOTHERUSER/current-guix instead of /var/guix-profiles/per-user/root/current-guix which it should be pointing at! I also think this is related to https://lists.gnu.org/archive/html/bug-guix/2020-01/msg00241.html Best regards, David Best regards, Mikael
bug#40123: glibc-locales: links missing in root user profile
Den ons 18 mars 2020 21:48david larsson skrev: > > > This led me to find my problem: For some reason, my > > ~root/.guix-profile was pointing to the current-guix profile rather > > than the guix-profile. > > > > It could have been me who did that. :( > > > > Anyway, problem solved! This was not a guix bug. > > Not so fast! I just did the same yesterday using the install-script but > on a RedHat server, and my /root/.config/guix/current pointed at > /var/guix/profiles/per-user/MYOTHERUSER/current-guix instead of > /var/guix-profiles/per-user/root/current-guix which it should be > pointing at! I also think this is related to > https://lists.gnu.org/archive/html/bug-guix/2020-01/msg00241.html I actually also think that there *is* a bug. But in my case it was either a lack in the documentation of how to setup .guix-profile or lack of getting this done automatically. This forced me into guesswork. David, for your problem, I'm wondering if it couldn't be related to what everyone has asked me: how you become root. Best regards, Mikael
bug#40123: glibc-locales: links missing in root user profile
On Wed, Mar 18, 2020 at 10:57:53PM +0100, Mikael Djurfeldt wrote: > David, for your problem, I'm wondering if it couldn't be related to what > everyone has asked me: how you become root. Usually when you need to "be root" it just means that you want superuser privileges, so people do `sudo su` or `sudo apt-get install foo`. It works to execute the command, and most of the time it doesn't matter which user actually runs the command. But Guix is specifically designed as a per-user package manager. Each user has their own view of "what is installed". It does matter who runs commands like `guix pull` and `guix package`, because those commands only affect the user who runs them. This is why we are careful when giving examples using sudo, saying either `sudo -E [--preserve-env]` or `sudo -i [--login]`, so that one explicitly chooses which user to be. The issue you had could be related...
bug#40123: glibc-locales: links missing in root user profile
On Wed, Mar 18, 2020 at 09:47:39PM +0100, david larsson wrote: > Not so fast! I just did the same yesterday using the install-script but on a > RedHat server, and my /root/.config/guix/current pointed at > /var/guix/profiles/per-user/MYOTHERUSER/current-guix instead of > /var/guix-profiles/per-user/root/current-guix which it should be pointing > at! I also think this is related to > https://lists.gnu.org/archive/html/bug-guix/2020-01/msg00241.html That's not good. To clarify, did you only run the installer script here? And made no manual changes related to Guix? I assume it was the GNU Guix 1.0.1 binary for x86_64 from here? https://guix.gnu.org/download/
