Re: Custom package, specifying cmake source directory?
Hi Matthew, ‐‐‐ Original Message ‐‐‐ On Monday, December 14, 2020 3:55 AM, Matthew Brooks wrote: > I'm working on a custom package definition, but when it gets built the cmake > files are in "source/src" instead of "source", and so the build system errors > out when trying to run cmake. How do I specify the source directory for the > cmake build system? > From grepping around in the definition for the cmake build system, it appears > that it expects the "source" variable to point to the appropriate location, > but I'm not at all familiar with scheme or guile, and I have no idea if > that's correct or how to change it. I'll try to answer you. I'm never played with this, but I think we can find something together. Cmake buildsystem has an interesting keyword argument called #:out-of-source? that chooses to compile the project inside sources or in a separate build directory. You need something similar, but not that. I tracked down that variable and I finally got into Cmake's configure step: I'm reading the contents of the file `guix/build/cmake-build-system.scm`. There you can find the definition of the `configure` step. You don't really need to do a lot in you package. You can replace the configure step with your own version of it, using the `sources/src` directory instead of what the default version uses. In order to replace the configure phase you need to do add a `#:phases` `argument` to your package and use a `modify-phases` call to `replace 'configure` with your own. (all the parts marked with backticks are literal code, grep them in the gnu/packages/ directory and you'll find examples). Your version could have the exact same contents that the default but with different directory. You just need to make a `chdir` to the place you like, just like this block (line 46 in guix/build/cmake-build-system.scm) does: ``` scheme (when out-of-source? (mkdir "../build") (chdir "../build")) (format #t "build directory: ~s~%" (getcwd)) ``` Remove all of it and change it with `(chdir "src")` or something like that and it should work. That's most of it. I just gave you a high-level explanation but you can ask me more if you need. Just ask anything you need. Best, Ekaitz
Re: Custom package, specifying cmake source directory?
Hi again, Let me re-answer because I think I screwed in a couple of points. So, you are not trying to use other build directory but a different source directory. That's a little bit different. Instead of making a `chdir` you need to touch the `srcdir` variable. In that case, you can change the current directory in a previous phase, adding a new phase before the `configure` step that just jumps to source code just like `hypre` does. Run `guix edit hypre` to see it: ``` scheme (add-before 'configure 'chdir-src (lambda _ (chdir "src"))) ``` Probably this last option is the best, I'm not sure if it works. It should. Sorry for the misunderstanding! Good luck, Ekaitz
Re: guix pull fails because substitution fails
Hi, On Sat, 12 Dec 2020 at 19:48, Thorsten Wilms wrote: > ``` > $ guix pull > > Updating channel 'guix' from Git repository at > 'https://git.savannah.gnu.org/git/guix.git'... Building from this > channel: guix https://git.savannah.gnu.org/git/guix.git > b828057 You were pulling b828057, but from which commit? > Trying to update a package also fails: > ´´´ > guix package -u inkscape > hint: Consider installing the `glibc-utf8-locales' or `glibc-locales' > package and defining `GUIX_LOCPATH', along these lines: > > guix install glibc-utf8-locales > export GUIX_LOCPATH="$HOME/.guix-profile/lib/locale" > > See the "Application Setup" section in the manual, for more info. > > guix package: warning: Your Guix installation is 10 days old. > guix package: warning: Consider running 'guix pull' followed by > 'guix package -u' to get up-to-date packages and security updates. > > The following package will be upgraded: >inkscape (dependencies or package changed) > > substitute: following redirection to > `https://ci.guix.gnu.org/nix-cache-info'... substitute: Backtrace: > substitute:3 (apply-smob/1 #) > substitute: In ice-9/boot-9.scm: > substitute: 705:2 2 (call-with-prompt _ _ # default-prompt-handle…>) substitute: In ice-9/eval.scm: > substitute: 619:8 1 (_ #(#(#))) > substitute: In guix/ui.scm: > substitute: 1579:12 0 (run-guix-command _ . _) > substitute: > substitute: guix/ui.scm:1579:12: In procedure run-guix-command: > substitute: In procedure put-string: Wrong type argument in position 1 > (expecting open output port): # guix package: > error: substituter `substitute' died unexpectedly > ´´´ What is the output of “guix pull -l” and “guix package -l”? What does “guix time-machine –commit=b828057 – help” say? All the best, simon
Re: guix pull fails because substitution fails
On Mon, 14 Dec 2020 14:28:48 +0100 zimoun wrote: > You were pulling b828057, but from which commit? ``` $: guix describe Generation 161 Dec 02 2020 14:24:58(current) guix 9fe5bb7 repository URL: https://git.savannah.gnu.org/git/guix.git branch: master commit: 9fe5bb7c9217f247a0fbbc72467ba5de3a6ddf03 ``` > What is the output of “guix pull -l” and “guix package -l”? What > does “guix time-machine –commit=b828057 – help” say? `guix pull -l` starts with: ``` Generation 1Nov 07 2018 21:45:53 guix b31e156 repository URL: https://git.savannah.gnu.org/git/guix.git branch: master commit: b31e1561611ebe4916890183b24e6e13cb83bf59 ``` Half an hour later (which makes me think you had something else in mind) it ends with: ``` Generation 161 Dec 02 2020 14:24:58(current) guix 9fe5bb7 repository URL: https://git.savannah.gnu.org/git/guix.git branch: master commit: 9fe5bb7c9217f247a0fbbc72467ba5de3a6ddf03 103 new packages: bcachefs-static, bcachefs-tools-static, cgoban, cl-array-operations, cl-check-it, cl-clamp, cl-claw-support, cl-clawk, cl-clesh, News for channel 'guix' Local substitute servers discovery is now supported commit 79f9dee3c4c0e6d21066f142116a537207ae7ba4 The `guix-daemon' can now discover local substitute servers when the `--discover' option is passed. Only the substitute servers started with the `--advertise' option will be discovered. The network discovery is based on mDNS and DNS-SD protocols, using Guile-Avahi library for now. ``` ``` $: guix package -l Generation 182 Nov 14 2020 10:38:14(current) glibc-utf8-locales2.31out /gnu/store/z7a6sbvqzb5zapwpznmjkq2rsxil6i67-glibc-utf8-locales-2.31 qrencode 4.0.2 out /gnu/store/28kraxb70gcdqxbj85ncr5pwc3g5mkvw-qrencode-4.0.2 pngcrush 1.8.13 out /gnu/store/318yvcifwvs92hhilas877piw4yhjl3r-pngcrush-1.8.13 font-ibm-plex 4.0.2 out /gnu/store/3yb65z1xhmgjgn119d90kpavp0b07nf6-font-ibm-plex-4.0.2 xmlstarlet1.6.1 out /gnu/store/2s8i216vjnavmd00x54qkg2glx18z3gq-xmlstarlet-1.6.1 rename1.10out /gnu/store/v7ii8kkhr57ara7n4ajlm6vajwfx5psc-rename-1.10 tree 1.8.0 out /gnu/store/9cfirwz0bk3n6gad4dy6qvxzf6kps597-tree-1.8.0 source-highlight 3.1.9 out /gnu/store/n0k5jn8y77d5gjnfiir68lh6cjnm7gqd-source-highlight-3.1.9 detox 1.3.0 out /gnu/store/7va9kc3wbc4ixrfxxadl557b4353njki-detox-1.3.0 aspell-dict-de20161207-7-0out /gnu/store/y47m34nvj9z5xjkv2w0wi3krvx6z2v8d-aspell-dict-de-20161207-7-0 zita-convolver4.0.3 out /gnu/store/j2iszgvvkn217zz19hn4gql2rqpmsdhn-zita-convolver-4.0.3 autotalent0.2 out /gnu/store/lrbdiwawr7xbcmccjw23bvrzply2n8ic-autotalent-0.2 jack 0.125.0 out /gnu/store/pz11x36fqzkblmc0vdk10ml94dqf0nv5-jack-0.125.0 flac 1.3.3 out /gnu/store/99bhlq1y4x4h3jlfhwm5a3v873wk6naz-flac-1.3.3 gnutls3.6.14 out /gnu/store/0f6agk6xk8rcz99907d39nd1vzmc4abq-gnutls-3.6.14 nss-certs 3.52.1 out /gnu/store/0llx3y194278l5ksr4xh9kc64mh8nn8d-nss-certs-3.52.1 libjpeg 9d out /gnu/store/1qpb4akvgi3l2zcdjrqs1apvzzxksglv-libjpeg-9d fdupes2.1.2 out /gnu/store/b2bqxnbi2ky56msplvz059fc1xs1ljar-fdupes-2.1.2 emacs-use-package 2.4 out /gnu/store/if9n8w8mkd80xggw01j9pip7vfqqbdnj-emacs-use-package-2.4 emacs-smex3.0 out /gnu/store/h3mir3cxkp34vb34zh2fri44s2gh8wxw-emacs-smex-3.0 emacs-rainbow-delimiters 2.1.4 out /gnu/store/51q75s4q2wn3alcim4j56xmygag5z5c3-emacs-rainbow-delimiters-2.1.4 emacs-paredit 24 out /gnu/store/1wb8yinahw2xqmf8cksg6kmrmapxjl6l-emacs-paredit-24 emacs-flx 0.6.1 out /gnu/store/l5sn7pxrdg8n5v26jvc6wdibdcg16675-emacs-flx-0.6.1 emacs-company 0.9.13 out /gnu/store/2vqbb5n1ak06hjngaxkda8vr6vgifczg-emacs-company-0.9.13 emacs-column-marker 9 out /gnu/store/yshx9xn9rn29yl97xl61pwywnwica8km-emacs-column-marker-9 emacs-rainbow-mode1.0.5 out /gnu/store/ph9cq24d3gvdrh88vwi3idgivzai376p-emacs-rainbow-mode-1.0.5 emacs-ivy 0.13.1 out /gnu/store/i0vbhylrx3c6cy8c1zi3v795kcgg5lab-emacs-ivy-0.13.1 emacs-counsel 0.13.1 out /gnu/store/ss0fjkan5g5bbmfd66azwkn0pqdb4cp9-emacs-counsel-0.13.1 swh-plugins-lv2 1.0.16 out /gnu/store/23kg3l012lj7n4jkqxmd56z5f7nrnivk-swh-plugins-lv2-1.0.16 mod-utilities 0-2.80ea3ea9f out /gnu/store/arrhn1r72jl6a3kngbrhqwasg9ay8852-mod-utilities-0-2.80ea3ea9f gx-voodoo-fuzz-lv20.1 out /gnu/store/2zb2yq1408ldhxday3wqdbn4xdbmmr92-gx-voodoo-fuzz-lv2-0.1 gx-vintage-fuzz-master-lv20.1 out /gnu/store/kdadhwgph50qqddw4w93yzf95k9i6mqs-gx-vintage-fuzz-master-lv2-0.1 gx-tone-mender-lv20-1.b6780b4a3 out /gnu/store/213nzjci9fsphjbwdrs4i2l41z1cmdsp-gx-tone-mender-lv2-0-1.b6780b4a3 gx-switchless-wah-lv2 0-2.7b0869120 out /gnu/store/yk1bc7798nhxjxl890fvwnyzjmplvhaz-gx
A weird thing about network connections in Icecat (and Firefox) on Guix
The same thing happens in Icecat as it does in nonguix's Firefox. (I mention the firefox thing to indicate that I *don't* think it's icecat-specific code). I've had this happen on my computer and have found it weird/disturbing for a while, but recently I found it's also happening on my spouse's computer, but only once she switched to Guix also. Wondering what's going on. (Maybe this should be filed as a bug, not sure.) Here's roughly the scenario: - Have icecat/firefox open and browsing websites. - Oops, something happens to the network. Maybe the wifi router goes out briefly or something. - You're back! You can ssh into servers again and connect to irc, and even ungoogled-chromium seems fine to browse websites. - But weirdly... you have to restart icecat/firefox for things to work right again. But weirdly... this isn't the case on my spouse's Debian install, etc. And I also only started experiencing it when I started running Guix. No particularly unusual extensions, just ublock origin, https everywhere, tree style tabs. I've turned off proxy settings in firefox to be sure. No change afaict. It's so strange. It's easy enough to fix but I'm disturbed that it's happening at all. It's as if there was some sneaky connection that firefox was making and which got broken until I restarted the browser. Or maybe it's just some massive caching bug that acts similarly. Disturbing. Anyone else experience the same? I tried describing this and it sounded like I was the only one having the issue a couple of years ago. Now that I'm not my only household member experiencing the same, I suspect we are probably not alone...? - Chris
Re: A weird thing about network connections in Icecat (and Firefox) on Guix
Hi Chris, Unsure if it's related, but I can reproduce this recipe on my Guix System with the Nyxt browser. - Enable Tor service. - Start Nyxt. - Enable proxy-mode over Tor. - Go to https://check.torproject.org/ to confirm it's working. - Put system to sleep for a while. - Wake up the the system and browse something from _an existing buffer_: most of the time it fails to load. Restarting the Tor service and/or opening a new buffer fixes it. Any idea? -- Pierre Neidhardt https://ambrevar.xyz/ signature.asc Description: PGP signature
Re: A weird thing about network connections in Icecat (and Firefox) on Guix
Pierre Neidhardt writes: > Hi Chris, > > Unsure if it's related, but I can reproduce this recipe on my Guix > System with the Nyxt browser. > > - Enable Tor service. > - Start Nyxt. > - Enable proxy-mode over Tor. > - Go to https://check.torproject.org/ to confirm it's working. > - Put system to sleep for a while. > - Wake up the the system and browse something from _an existing buffer_: > most of the time it fails to load. > > Restarting the Tor service and/or opening a new buffer fixes it. > > Any idea? Curious, except that afaict I shouldn't be running a proxy here, and afaik neither is my spouse, who didn't experience this behavior until the Guix switchover either (and isn't running the tor service atm). I did wonder if this was proxy-like failure behavior though.
