bug#37361: GHCI fails to run for ghc@8.6.5
Hi Jacob, Jacob MacDonald writes: >> I believe this should be fixed by 83aa656217. > > That does indeed fix both bugs. In my specific case I'm still running > into an issue with dependency shadowing, but it seems like a separate > issue and I'll open a new one if it's not on my side. > > Thanks. Thanks for checking so quickly. :) -- Tim
bug#37318: [PATCH] OpenNTPD generated config is convoluted
Hello, Efraim Flashner writes: > On Sat, Sep 07, 2019 at 01:21:27PM +0900, Maxim Cournoyer wrote: >> Hello, >> >> The attached patches fix this issue as well as the openntpd package not >> being able to load the CA cert used to authenticate constraint servers. >> >> It depends on the NTP patches posted here: bugs.gnu.org/37295. >> > > This set also looks good to me. Make sure you don't forget any copyright > lines for yourself. I thought I had answered already, but it seems my reply wasn't sent. Fixed in commit cccdfae388d61f2263a085a4ddac8cb2919d01531. Thanks for the review! Maxim
bug#37361: GHCI fails to run for ghc@8.6.5
> I believe this should be fixed by 83aa656217. That does indeed fix both bugs. In my specific case I'm still running into an issue with dependency shadowing, but it seems like a separate issue and I'll open a new one if it's not on my side. Thanks.
bug#37361: GHCI fails to run for ghc@8.6.5
Hi Jacob, Jacob MacDonald writes: > To reproduce, just guix environment --ad-hoc ghc -- ghci. ghc@8.4.3 > works. Seems like this may be related to some Prelude changes upstream > (https://gitlab.haskell.org/ghc/ghc/issues/16563), but I'm not > familiar enough with GHC internals to really tell what's going on. > Interestingly, when I try to run plain old GHC on some source files > with 8.6.5 I get another seemingly unrelated error: > > Bad interface file: > /gnu/store/8v1sn5ns7r5n02aip0b0ypyyzb2y1i1a-ghc-8.4.3/lib/ghc-8.4.3/base-4.11.1.0/Prelude.hi > mismatched interface file versions (wanted "8065", got "8043") > | > 1 | import Test.Hspec(Spec, it, shouldBe) > | ^ I believe this should be fixed by 83aa656217. I made a mistake when refactoring the GHC 8.6 package definition, and it was not setting its search paths correctly. Can you try again and confirm that it’s fixed? Thanks! -- Tim
bug#37064: Ghc 8.6.5 fails to find core package database
Hi again,
Timothy Sample writes:
> Gabriel Giamarchi writes:
>
>> Installing only 'ghc 8.6.5' (Glasgow Haskell compiler) and sourcing
>>
>> '~/.guix-profile/etc/profile' leads to ghc not finding core modules.
>> ('ghci' doesn't find System.IO for instance).
>>
>> This is due to $GHC_PACKAGE_PATH not containing ghc 8.6.5's
>> package.conf.d, but
>> instead ghc 8.4.3's database.
>>
>> Note: Not setting this variable leads to a working ghc (will search in
>> default
>> location), but is required to install additional packages via guix.
>>
>> The issue might come from guix/profiles.scm:812, since
>> (module-ref (resolve-interface '(gnu packages haskell)) 'ghc)
>> evaluates to in my repl.
>
> Good catch. I can confirm this is the issue, but I’m not sure how to
> fix it. We could try to find GHC from the profile rather than
> unconditionally using a certain package. However, that would not help
> if someone were to install GHC 8.4 and 8.6 in the same profile.
I took another look at this and we were wrong! The main issue here is
that I made a mistake in the GHC 8.6 package definition, and it was
setting GHC_PACKAGE_PATH incorrectly. This should be fixed as of commit
83aa656217. Sorry for the trouble.
Note that you will likely run into trouble trying to use other
Guix-provided Haskell packages with GHC 8.6, as they are all built with
GHC 8.4. AFAIU, this is not something that GHC supports.
-- Tim
bug#26302: [website] translations
On Sun, 08 Sep 2019 12:16:38 -0500 pelzflorian (Florian Pelz) wrote > > Regarding URLs, I would prefer using IRIs, like follows: > > > > /IETF-LANGUAGE-TAG/path/to/resource/ > > > > So: > > > > /es-ES/vídeos/ > > /es-CO/videos/ > > > > As I understand it, es and es-ES and es-Latn-ES would all be language > tags (or just subtags??) for Spanish from Spain. Do we use the full > tag es-Latn-ES? Probably es-ES makes more sense than es-Latn-ES for > many languages (but not all). The Translation Project will generally > only provide one script, it seems. Maybe often es is enough. I > suppose we could write an associative list mapping locales for which > translations exist to language tags. I'm not suggesting any particular IETF language tags for Spanish variants, though. I think one could start supporting only the language tags equivalent to the teams defined in the Translation Project (TP). In the case of Spanish, many libre projects start focusing only on "es" (which is the case for the TP), and that's ok, but it's good to support variants. As far as I understand, the TP allows creating teams for language variants (there is a pt_BR team). For example, I'd like to have an "es-CO" catalog to override some translations of the "es" catalog that are only common in Spain.
bug#37363: emacs and other programs do not display special characters
As per nckx's question on IRC, this is the output to locale on both Emacs shell and BASh: quiliro@GSD3 ~/magit/prueba0$ locale LANG=es_EC.UTF-8 LC_CTYPE="es_EC.UTF-8" LC_NUMERIC="es_EC.UTF-8" LC_TIME="es_EC.UTF-8" LC_COLLATE="es_EC.UTF-8" LC_MONETARY="es_EC.UTF-8" LC_MESSAGES="es_EC.UTF-8" LC_PAPER="es_EC.UTF-8" LC_NAME="es_EC.UTF-8" LC_ADDRESS="es_EC.UTF-8" LC_TELEPHONE="es_EC.UTF-8" LC_MEASUREMENT="es_EC.UTF-8" LC_IDENTIFICATION="es_EC.UTF-8" LC_ALL=
bug#37363: emacs and other programs do not display special characters
Hello Guix: I am reporting this because there are no other similar cases on the mailing list and because I think this might be a bug and not my error. Emacs Magit and Emacs shell don't dispaly special characters (such as ñ, í, ó) on their output. It is strange because a command that includes a special character is displayed. But a special character from the output will not be displayed correcly. Those special characters are displayed correctly on afairs such as opening a file with those characters. With 'emacs -Q' I did not have that problem. When copying .emacs.d to another directory, setting that directory as HOME and running emacs with 'mkdir ~/temp', 'cp ~/.emacs.d ~/temp/' and 'HOME="~/temp" emacs', it would not use my configurations. But it would not have the problem with Emacs shell. Emacs Magit would not be available either. The same situation is with 'emacs -Q' as with 'HOME="~/temp" emacs'. Sample from BASh displaye correctly: quiliro@GSD3 ~/magit/prueba0$ git log commit 0904ec46cb737d2116d59b0b7c4f0c21a74feb70 (HEAD -> master) Author: quiliro Date: Sun Sep 8 15:43:09 2019 -0500 Modificación remota commit 5024f6d525b1b61cd269160dde07ae6f489f (origin/master) Author: ramiro.ordonez Date: Sun Sep 8 13:20:11 2019 -0500 Añadí a mi amor quiliro@GSD3 ~/magit/prueba0$ Same command sample from Emacs shell displayed incorrectly: quiliro@GSD3 ~/magit/prueba0$ git log WARNING: terminal is not fully functional - (press RETURN) commit 0904ec46cb737d2116d59b0b7c4f0c21a74feb70 (HEAD -> master) Author: quiliro Date: Sun Sep 8 15:43:09 2019 -0500 Modificación remota commit 5024f6d525b1b61cd269160dde07ae6f489f (origin/master) Author: ramiro.ordonez Date: Sun Sep 8 13:20:11 2019 -0500 Añadà a mi amor quiliro@GSD3 ~/magit/prueba0$ I am not sure if this is related that in Icecat I sometimes see square boxes with numbers inside them in place of characters. But other special characters are displayed. That is probably a missing font. It could be a separate problem. Happy hacking!
bug#37357: Guix gc removes next-gtk-webkit input with next installed
Dimakakos Dimos writes: > After running gc and trying to launch next-browser I get: […] > [19:11:30] next base.lisp (initialize-port remote-interface fun24) - > Couldn't execute > "/gnu/store/5hh6qpp4lqa6gy1ghdb4ppvjamgb3mbc-next-gtk-webkit-1.3.1/bin/next-gtk-webkit": > No such file or directory […] > Obviously the package should be live and not be picked up by gc, since > it's an input of a package in a current profile. Any ideas why that > could happen? Can you tell us what version of Guix you used to install Next? There was a short period during which the Next executable was compressed, which effectively hid references from the garbage collector. -- Ricardo
bug#37361: GHCI fails to run for ghc@8.6.5
To reproduce, just guix environment --ad-hoc ghc -- ghci. ghc@8.4.3 works. Seems like this may be related to some Prelude changes upstream (https://gitlab.haskell.org/ghc/ghc/issues/16563), but I'm not familiar enough with GHC internals to really tell what's going on. Interestingly, when I try to run plain old GHC on some source files with 8.6.5 I get another seemingly unrelated error: Bad interface file: /gnu/store/8v1sn5ns7r5n02aip0b0ypyyzb2y1i1a-ghc-8.4.3/lib/ghc-8.4.3/base-4.11.1.0/Prelude.hi mismatched interface file versions (wanted "8065", got "8043") | 1 | import Test.Hspec(Spec, it, shouldBe) | ^ Again, I'm afraid I'm not entirely familiar with GHC internals and the function of interfaces files. Nevertheless, it seems not all is well in Guix-Haskell-land.
bug#36965: streamlink fails to run.
I noticed this bug a while back but didn't think to submit it to debbugs and didn't make the connection to the 2->3 transition. Happy to help you hunt this one, and may take a look in that direction now that you've set me on an unexplored path.
bug#37345: Icecat doesn't display numbers on Guix System
‐‐‐ Original Message ‐‐‐ On Monday, September 9, 2019 1:15 PM, Jan wrote: > > I got this too when I first installed icecat. > > I am not sure why, but I got no readable presentation > > from icecat until I had done > > guix install font-dejavu > > This one helps, thanks a lot! > > > Jesse's fc-list suggestion indicates that the Nimbus fonts ought to > > come in by > > guix install gs-fonts > > maybe that would work as well as or better than > > guix install font-dejavu > > Idk :) > > This doesn't help. > > Anyway shouldn't the font-dejavu package be a dependency of Icecat then? > > Jan Wielkiewicz Didn't the older bug report's thread mention something about having to manually rebuild some kinda font database or cache? I remember trying that and that fixed it for me.
bug#37357: Guix gc removes next-gtk-webkit input with next installed
After running gc and trying to launch next-browser I get: [19:11:29] next base.lisp (start) - NEXT::+VERSION+: "1.3.1" [19:11:29] next base.lisp (load-lisp-file form-fun-4) - Loading configuration from /home/bendersteed/.config/next/init.lisp... [19:11:30] next minibuffer.lisp (echo) - Can't echo 'MINIBUFFER-MODE enabled.' without minibuffer or interface [19:11:30] next remote.lisp (ensure-dbus-session form-fun-4) - Bus connection name: :1.103 [19:11:30] next remote.lisp (initialize-instance :after remote-interface) - Bus connection name: :1.104 [19:11:30] next port.lisp (run-program port) - Current directory: /home/bendersteed/ [19:11:30] next port.lisp (run-program port) - Platform port path: /gnu/store/5hh6qpp4lqa6gy1ghdb4ppvjamgb3mbc-next-gtk-webkit-1.3.1/bin/next-gtk-webkit [19:11:30] next port.lisp (run-program port) - Platform port arguments: NIL [19:11:30] next port.lisp (run-program port) - Platform port log file: /home/bendersteed/.local/share/next/next-gtk-webkit.log [19:11:30] next base.lisp (initialize-port remote-interface fun24) - Couldn't execute "/gnu/store/5hh6qpp4lqa6gy1ghdb4ppvjamgb3mbc-next-gtk-webkit-1.3.1/bin/next-gtk-webkit": No such file or directory Make sure the platform port executable is either in the PATH or set in you ~/.config/next/init.lisp, for instance: (setf (get-default 'port 'path) "~/common-lisp/next/ports/gtk-webkit/next-gtk-webkit") ; ; compilation unit aborted ; caught 1 fatal ERROR condition Obviously the package should be live and not be picked up by gc, since it's an input of a package in a current profile. Any ideas why that could happen?
bug#37345: Icecat doesn't display numbers on Guix System
> I got this too when I first installed icecat. > I am not sure why, but I got no readable presentation > from icecat until I had done > guix install font-dejavu This one helps, thanks a lot! > Jesse's fc-list suggestion indicates that the Nimbus fonts ought to > come in by > guix install gs-fonts > > maybe that would work as well as or better than > guix install font-dejavu > > Idk :) This doesn't help. Anyway shouldn't the font-dejavu package be a dependency of Icecat then? Jan Wielkiewicz
bug#37345: Icecat doesn't display numbers on Guix System
> Looks like it isn't finding the "Nimbus Sans L" font. Try running > > fc-list | grep "Nimbus Sans L" > > and reply with the output. Here is the output /gnu/store/ag8ilfwcnxn0xnw8bar9ia73h3hg3rra-gs-fonts-8.11/share/fonts/type1/ghostscript/n019004l.pfb: Nimbus Sans L:style=Bold /gnu/store/ag8ilfwcnxn0xnw8bar9ia73h3hg3rra-gs-fonts-8.11/share/fonts/type1/ghostscript/n019064l.pfb: Nimbus Sans L:style=Bold Condensed Italic /gnu/store/ag8ilfwcnxn0xnw8bar9ia73h3hg3rra-gs-fonts-8.11/share/fonts/type1/ghostscript/n019003l.pfb: Nimbus Sans L:style=Regular /gnu/store/ag8ilfwcnxn0xnw8bar9ia73h3hg3rra-gs-fonts-8.11/share/fonts/type1/ghostscript/n019044l.pfb: Nimbus Sans L:style=Bold Condensed /gnu/store/ag8ilfwcnxn0xnw8bar9ia73h3hg3rra-gs-fonts-8.11/share/fonts/type1/ghostscript/n019043l.pfb: Nimbus Sans L:style=Regular Condensed /gnu/store/ag8ilfwcnxn0xnw8bar9ia73h3hg3rra-gs-fonts-8.11/share/fonts/type1/ghostscript/n019063l.pfb: Nimbus Sans L:style=Regular Condensed Italic /gnu/store/ag8ilfwcnxn0xnw8bar9ia73h3hg3rra-gs-fonts-8.11/share/fonts/type1/ghostscript/n019023l.pfb: Nimbus Sans L:style=Regular Italic /gnu/store/ag8ilfwcnxn0xnw8bar9ia73h3hg3rra-gs-fonts-8.11/share/fonts/type1/ghostscript/n019024l.pfb: Nimbus Sans L:style=Bold Italic Jan
bug#37249: console shell upon login is not ~/.guix-profile/bash -- is this always/never ok?
On +2019-09-07 16:50:12 +0800, 宋文武 wrote: > 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. > Hi ???iyzsong, Thank you for caring to answer, and for your time working on it! Unfortunately for me, perhaps, I am interested in pursuing purity in the definition of systems, so "shoulds" are not that reassuring ;-) I think your advice, > "... you might try the guix system if have so much > choices trouble you :-) may be the easiest way to improve my current situation, so I will see about doing that. Thanks :) [...] > > 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. > Yes, but I don't normally type bash -- I type the name of some script I've written and put in ~/bin, and it was typically written years ago with a #!/usr/bin/bash first line, and I don't want to have to modify all those ;-) Especially those that I might have put in a personal git repo. Would I have to, to migrate all those little helpers to my GuixSD ?? [...] > > [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 :-) > Until I have to diagnose a difference in behaviour ;-) > > > > 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). > I meant namespace in the general sense of a "space" to look for the meaning of a name in, sorry to abuse the term. Anyhow, that "sometimes" leaves me guessing ;-) > > > > Ok, here is the grep: [...] > > 162 #!/usr/bin/env python3 > > 167 #!/bin/bash > > 169 #!/usr/bin/env python > > 207 > > #!/gnu/store/iqx98v4rnw26n4qn555l4pbj96navxiv-python2-2.7.15/bin/python > > 209 > > #!/gnu/store/g87hamjyipk1j6dfq5pjfzfnfb64spbv-python2-2.7.15/bin/python > > 228 #!/bin/sh > > 292 > > #!/gnu/store/5s2nib1lrd2101bbrivcl17kjx1mspw6-coreutils-8.30/bin/false > > 292 > > #!/gnu/store/8z9avbgm73nzrbkhscps68gcpfipgllc-bootstrap-binaries-0/bin/false > > 319 #!/gnu/store/dna8kpb00kq176rz8x69yy4j33my2q55-perl-5.28.0/bin/perl > > -w > > 362 #!/bin/bash > >1589 #!/gnu/store/dna8kpb00kq176rz8x69yy4j33my2q55-perl-5.28.0/bin/perl > >2706 > > #!/gnu/store/q19l04vd2za80mk1845pz7r8cz29qk43-bash-minimal-4.4.23/bin/bash > >3294 > > #!/gnu/store/q19l04vd2za80mk1845pz7r8cz29qk43-bash-minimal-4.4.23/bin/sh > >3871 #!/gnu/store/qn1ax1fkj16x280m1rv7mcimfmn9l2pf-bash-4.4.23/bin/bash > > - > > Yeah, a guix package should patch all those shell interperters from > /bin, /usr/bin, etc to the store path under /gnu/store, but may miss > some cases (which should be fixed). > I can live with work in progress ;-) [...] > > I have set SHELL=/home/bokr/.guix-profile/bin/bash in ~/.bash_profile, > > but as seen, that doesn't take effect for the
bug#37345: Icecat doesn't display numbers on Guix System
On +2019-09-08 19:05:22 -0600, Jesse Gibbons wrote: > Hi Jan, > On Mon, 2019-09-09 at 00:18 +0200, Jan wrote: > > Okay, I found some probably more helpful info - I run icecat in a > > terminal and it throws the following warnings, don't know if they're > > related to this bug though: > > ... > > (/gnu/store/8pjdh78z3j2issz78yjmf94k3hlkrb5f-icecat-60.9.0- > > guix1/lib/icecat/.icecat-real:4648): > > Pango-WARNING **: 22:11:58.541: failed to create cairo scaled font, > > expect ugly output. the offending font is 'Nimbus Sans L > > 9.9990234375' > > I got this too when I first installed icecat. I am not sure why, but I got no readable presentation from icecat until I had done guix install font-dejavu The steps prior to that, and after were: guix package -i nss-certs guix upgrade icecat guix install fontconfig guix install libxfont guix install font-dejavu -->> and that gave icecat font guix install moka-icon-theme guix install hicolor-icon-theme guix install less libxfont notably did nothing for me, but idk if fontconfig was either interfered or did something good. You might consider installing font-dejavu After getting a usable display, there was another error produced by an add-on, which I was able to disable from the menu at the top right. Sorry not to remember details on that. I generally dislike add-ons or anything else that comes preconfigured to do any action without my consent. R_my_F, icecat ;-/ Jesse's fc-list suggestion indicates that the Nimbus fonts ought to come in by guix install gs-fonts maybe that would work as well as or better than guix install font-dejavu Idk :) HTH [...] > > > > Jan Wielkiewicz > > > > > > > Looks like it isn't finding the "Nimbus Sans L" font. Try running > > fc-list | grep "Nimbus Sans L" > > and reply with the output. > -- > -Jesse > Regards, Bengt Richter
bug#37348: Force https redirect missing from ci, workflow and workflows guix.info sub-domains
Collin J. Doering writes: > Not sure where the best place to report this, however today I noticed > that ci.guix.info, workflow.guix.info and workflows.guix.info do not > redirect http to https, though its also served over https. I'm unsure if this is intentional, or something to change. There are security advantages to forcing all users to use HTTPS, with the disadvantage that some of those users might not want to use HTTPS. I'm not sure whether the need for security on those domains is high enough to justify not supporting plain HTTP... signature.asc Description: PGP signature
bug#37347: 'guix environment' fails after trying to follow the steps from "Running Guix Before It Is Installed" page
Le 9 septembre 2019 03:14:05 GMT+02:00, Jesse Gibbons a écrit : >On Mon, 2019-09-09 at 02:49 +0200, Jan wrote: >> Hi, I'm a new Guix user and I wanted to hack on Guix and update a >> package, I hadn't known exactly how to do this, so I started >> following >> instructions from >> https://guix.gnu.org/manual/en/html_node/Running-Guix-Before-It-Is-In >> stalled.html#Running-Guix-Before-It-Is-Installed >> and >> https://guix.gnu.org/blog/2018/a-packaging-tutorial-for-guix/ >> >> The situation started to be interesting, when the tutorial told me to >> run "cd $GUIX_CHECKOUT" and "./pre-inst-env guix package >> --list-available=ruby" >> I was confused, because I couldn't find any "./pre-inst-env" file, so >> I >> used 'find' to search for it and there were one file with a similar >> name >> in $GUIX_CHECKOUT/build-aux - ./pre-inst-env.in (as I'm composing >> this >> email now I see that's stupid, but I tried using this file, as I >> don't >> know what I was doing (still don't know)) >> So I started running the following stupid commands: >> >> >> user@machine ~/Prog/repo/guix [env]$ sudo -E ./pre-inst-env.in >> guix-daemon --build-users-group=guixbuild >> >> sudo: /gnu/store/z26h622slm8p61myhk45v3jjg8p7qm8z-profile/bin/sudo >> must >> be owned by uid 0 and have the setuid bit set >> >> user@machine ~/Prog/repo/guix [env]$ ./pre-inst-env.in >> bash: ./pre-inst-env.in: No such file or directory >> user@machine ~/Prog/repo/guix [env]$ cd build-aux/ >> user@machine ~/Prog/repo/guix/build-aux [env]$ sudo >> -E ./pre-inst-env.in guix-daemon --build-users-group=guixbuild >> sudo: /gnu/store/z26h622slm8p61myhk45v3jjg8p7qm8z-profile/bin/sudo >> must >> be owned by uid 0 and have the setuid bit set >> user@machine ~/Prog/repo/guix/build-aux [env]$ exit >> --- >> >> And then: >> >> -- >> user@machine ~/Prog/repo/guix/build-aux$ chmod +x ./pre-inst-env.in >> user@machine ~/Prog/repo/guix/build-aux$ sudo -E ./pre-inst-env.in >> guix-daemon --build-users-group=guixbuild Password: >> ./pre-inst-env.in: line 33: cd: @abs_top_srcdir@: >> there is no such file or directory >> ./pre-inst-env.in: line 34: cd: >> @abs_top_builddir@: there is no such file or directory >> >> >> And after that I couldn't run "guix >> environment" anymore, it threw an error: >> >> guix environment: error: failed to connect to >> `/var/guix/daemon-socket/socket': Connection refused >> >> Restarting the computer helps, but doing the same stuff breaks it >> again, so guess it's reproducible. >> >> After doing it I ran the "history" command so you can know what I did >> exactly (some commands were unfortunately run in an environment and I >> can't provide them), here it is: >> >> 371 git clone --recurse-submodules >> git://git.savannah.gnu.org/guix.git >> 372 guix environment guix --pure >> 373 sudo -E >> 374 sudo --help >> 375 guix environment guix --pure >> 376 guix environment guix --pure --ad-hoc sudo >> 377 ls >> 378 cd guix/ >> 379 ls >> 380 cd build-aux/ >> 381 ls >> 382 . >> 383 guix environment guix --pure >> 384 chmod +x ./pre-inst-env.in >> 385 sudo -E ./pre-inst-env.in guix-daemon >> --build-users-group=guixbuild >> 386 ls >> 387 cd .. >> 388 ./configure >> 389 guix environment guix --pure >> 390 history >> >> As stupid and complicated as it is, something is definitely broken >> here. >> >> Sincerely, >> Jan Wielkiewicz >> >> >> > >pre-inst-env.in is for generating the pre-inst-env script. Have you >tried: >./bootstrap >./configure > >This should generate pre-inst-env for you. > >Also, make sure the guix daemon is running after you restart. Do not run ./configure alone, always specify --localstatedir=/var unless you plan to run the daemon from the repo too (then it's fine without the option, but you won't be able to pull or you'll get into trouble iiuc).
