IRC channel logs
2024-03-23.log
back to list of logs
<mik3d>why does it never find the right guile.ac? ./configure: line 2721: `GUILE_PKG(3.0)' <jaft>enzuru: I can't speak to if this actually makes any kind of difference but, just looking at my home config. file, I noticed that I'm just using a ~simple-service~; so the equivalent, for what you're doing, would be ~(simple-service 'name-of-service home-mcron-service-type (list job-clear-cache job-updatedb job-tag-mail))~. <ulfvonbelow>I've figured it out: the derivations produced by 'guix pull' were nondeterministic. Now to see whether that was an issue specific to the version of guix installed by the 1.4.0 installer... <podiki>wow the nss test suite takes forever.... <Passenger>Hi guix! I've found this message while installing programms, mostly related to R? "/sha256 hash mismatch for /gnu/store/...-pan_1.9.tar.gz: <Passenger> expected hash: 0liwcym035174h6c4b9ddmqxa3vkpkk3alyr9psk8yhv7i61hzp3 <Passenger> actual hash: 1skfdh8mg3hs9h651shyn80maas71jlbmvn06izym0rpclnj74fd <Passenger> How to fix it? Only by sending patch, request? <janneke>Passenger: try guix gc --delete /gnu/store/...-pan_1.9.tar.gz (use the actual file name) <Passenger>janneke, I tried, it didn`t work unfortunately. <Passenger>janneke, Now I deleted with one command that pan_1.9.tar.gz and pan_1.9.tar.gz.drv. It deleted by itself also r-pan...drv. It is working and continue to compile, let`s see. Anyway thanks a lot for help! <ulfvonbelow>seems mesa now has to be explicitly told to build the i915 driver <Pablo->I am facing an issue while trying to build 'bitwarden' from source. The dependencies does not seem to be present during the build and the daemon has no network to collect them. I was not able to find a workaround to install the dependencies before the 'configure' phase, which then shows error : <Pablo->(define-module (my-packages my-bitwarden) <Pablo-> #:use-module (guix build-system node) <Pablo-> #:use-module (guix gexp) ; for '#~' <Pablo-> #:use-module (guix git-download) <Pablo-> #:use-module ((guix licenses) #:prefix license:) <Pablo->It has to see with 'npm-build-system'. Anyone who has experience with that kind of issue ? <Pablo->This is my first request so in case I am not asking at the right place, do not hesitate to tell me where to go, what to provide. <fnat>Hi Pablo-, I think this is the right place! However, I'd suggest you use a paste service (e.g. https://paste.debian.net/) to paste your code as there are limits in terms of how many lines you can dump in a IRC channel (netiquette). <Pablo->I will do so and confirm as soon as done. Thank you. <fnat>Pablo-: Not a node/npm expert here, but you might need to add some dependencies as part of the input field. <fnat>Have you looked at any other similar packages, e.g. in `node-xyz.scm' (in the Guix repository)? <Pablo->I search if they were existing in the kind of 'node-DEPENDENCIES' as for the pip packages for python3 called 'python-MODULE' but I do not know were to search. <Pablo->Yes I looked at those package but did not find anyone having faced the same issue so far. <Pablo->I also read the 'node-build-system.scm' file in order to understand the low level and so far I understood that npm has no access to network because during the configure phase, it uses 'npm --offline ...' to install the dependencies. <fnat>A `guix search <keyword>' should show them, if they've been packaged - but chances are that you might need to package something else too. <janneke>Pablo-: have a look at gnu/packages/node-xyz.scm for packages and usage of the (inputs ...) field <Pablo->If I am not wrong, there is no general pattern in the package added. It seems that some packages adds dependencies (one, two) but nothing that I can learn from. No documentation on the manual and no history for node packages- <Pablo->npm ERR! code EUNSUPPORTEDPROTOCOL <Pablo->npm ERR! Unsupported URL Type "workspace:": workspace:* <fnat>Pablo-: I think these are aspects that are not really specific to node/npm. E.g. the lack of network access is by design in all build systems (I think, others might correct me), e.g. to guarantee reproducibility. <Pablo->Of course, I agree. The network missing is a fact - but I am trying to find a workaround and could not so far (~20hours of debug ongoing). <janneke>iirc, yarn has thousands of dependencies and many dependency cycles and cannot (easily) be built from source <fnat>I don't know about Bitwarden, but you might want to start with a simpler package to familiarise a bit with the process. <janneke>oh wait, forget that, i was thinking of gradle -- don't know anything about yarn <Pablo->You mean - familiarise with the package built through 'npm-build-system' ? Because I already build package with 'cmake' 'gnu' and another build system that I do not remember. <fnat>Pablo-: Sorry, my bad for assuming you needed to practice with the process. <Pablo->It's okay. I like to hear feedback from other 'Guix' in order to enhance my 100% self-taught skills. It is great to get other user experience and approach about the point of view. <Pablo->And thank you again for helping. <Pablo->Regarding the dependencies, I would like that the node-build-system would download them on the same step a the source but I do not know how to process. I tried to test the network before and after the 'unpack' phase, as well as before the 'configure' phase with 'ping' and 'curl'. With 'ping' I cannot ping 'gnu.org' due to missing permission to <Pablo->write on socket and with 'curl' it seems that no network is available during those phases. <fnat>Pablo-: This thread might be relevant to what you're trying to do: https://issues.guix.gnu.org/33431 It's not good news, but I'd encourage you to bring this up in the mailing list as someone might give you some broader feedback or maybe mention some recent positive update. <pfna>Has anyone used the guix build system to forego the makefile entirely for certain packages? <Pablo->Ok, so to write to this e-mail address 'bug-guix@gnu.org' ? I sent a 'dummy test' a few minutes ago but did not see any new issue opened of the 'https://issues.guix.gnu.org/' website. This is my first request so am I right to contact 'bug-guix@gnu.org' or should I prefer 'help-guix@gnu.org' ? <Pablo->I know it seems to be a dummy question but I am not sure how to process. I would like to ensure to understand the protocol to submit that kind of 'issue'. <janneke>Pablo-: the mailing lists are moderated; that may take some time on your first post <Pablo->Thank you for confirming janneke. It is better than nothing. I will submit a request and tried to debug by myself to learn (tough coding enhance development skills!). Could you please just confirm whether I should write to 'bug-guix@gnu.org' or 'help-guix@gnu.org' ? <janneke>bug-guix@gnu.org: If you found a bug in Guix, check whether the bug is already in the bug database. If it is not, please report it. <janneke>if it's not a bug, don't send to bug-guix :) <jas>hi! anyone using zfs on guix? i wonder how stable and proven this is? i'm not looking for rootfs usage, just adding a large zfs pool for several disks <ebrasca>Hello, I start using guix home and my zsh stop reading its .zshrc file. <hapst3r>When building a package with Guix, is the entire source tree - base source files and what is created during the build process - kept after successful install? <hapst3r>I am trying to build a New package Version, and while the old Version builds no Problem, the New Version throws an irritating error (access to file denied), and I'd love to compare the source trees to better understand <jpoiret>the source files you can get with the `-S` option of guix build <jpoiret>but the build directory is not kept, if you want to keep it you can add a dummy phase at the end of the build and make it fail, in conjunction with the `-K` option <mik3d>what emacs irc client you recommend <mdupont>yeah going to use erc and emacs now, sick of this mobile interface. <JustaPassenger>Hi, guix. Problem still persists. When installing programs this error is appeared -sha256 hash mismatch for /gnu/store/86hi45dck4i7vwx2qzwyn2whwmdnfgbj-pan_1.9.tar.gz: <JustaPassenger> expected hash: 0liwcym035174h6c4b9ddmqxa3vkpkk3alyr9psk8yhv7i61hzp3 <JustaPassenger> actual hash: 1skfdh8mg3hs9h651shyn80maas71jlbmvn06izym0rpclnj74fd <mdupont>so I have been stuck trying to build cuirass it is failing, `guix shell --develop cuirass` is failing it seems on the test. The only error I see in the logs is 'Fontconfig error: No writable cache directories'. doing the `export XDG_CACHE_HOME="$(mktemp -d)"` before did not help. <ae_chep>Could I get some attention on 69023 please? It has been a few weeks <ghisvail>My apologies if it's been already reported, but I can't download the latest Guix System image built by Cuirass. <ghisvail>I get a JSON payload with `error: "Could not find the requested build product."` <enzuru>jaft: thanks for the advice, i'll look into that <PotentialUser-86>Hello. Noob here. I continue to try and wrap my head around "The Guix Way" of doing some things and seek some help/aid/opinions. <PotentialUser-86>For example, I notice that several packages lag behind the most recent releases, so I'm looking to see how hard would it be to update them. I'm trying Python 3.12 and it is quite the effort. <PotentialUser-86>I have read there is a "Python team/group". Is there a way to contact them? <PotentialUser-86>I also understand that some tests may fail on the build environment. But not all. Why would calls to fork() fail or present a challenge in the build environment? <jaft>PotentialUser-86: This doesn't /actually/ answer your question but, if it's helpful, it looks like Python 3.12 is already packaged up, as =python-next=, so there's no need to build it, yourself. <jaft>You could take a look at the definition in the source code (at https://git.savannah.gnu.org/cgit/guix.git, I believe) and see what was done differently between v3.12 and v3.10 (looking at it, it does seem to require a substantially different approach but I don't remotely know enough about Python development to say why). <jaft>For what it's worth, I – also – often can't tell, when tests fail, why they did and I think it just requires a greater understanding of the language's build processes (which, unfortunately, I often don't have). Some common causes I've encountered is that the build environment doesn't allow internet calls (for reproducibility purposes) so tests which test internet operations will often fail. Packages which depend on <jaft>a DE (often Gome packages, for example) will need some smoothing out regarding having an X11 process running or the like. I can't speak to your Python-specific cases you've bought up but those have been some I've encountered; usually something out of place (that, again, I'd feel like I'd know to look for if I was more familiar witht the language's testing practices or something). Someone else here may be able to provide a more helpful <jaft>answer of this but those have been my experience. <mdupont>ok so i got a package to build on one server, how to extract the exact deps to rebuild on another ? <pfna>Is it possible, on guix, to have two separate drivers running for a system, where a singular application can be made into two packages that individually access separate drivers? <pfna>Basically, I'm curious if I could use guix's principles to run the same application twice: once for my amd gpu and once for my nvidia gpu <mdupont>wow so i am able to export and import a build now but still cannot figure out how to reproduce the build, any ideas? <mdupont>sent another mail to the list in hopes of getting some support. <mccd>heya, I'm trying to get guix to work on Nixos <mccd>running into the issue "cannot build derivation `/gnu/store/fj2bawm6a8algp5vqfvy9zc4qzyswq36-compute-guix-derivation.drv': 1 dependencies couldn't be built" when running guix pull <mccd>using the default install tool and running guix daemon as sudo guix-daemon <mccd>any clue what I'm missing? <mdupont>i did the other way around and built nix on guix <mccd>and yeah at some point I want to switch to full guix, but I'm not quite ready yet haha <pfna>Does guix have a standard way of editing a defaults.mk makefile before building? <mdupont>ok peanuts, autoconf is failing. so lets try and build that? `guix shell -D autoconf` and `guix build -k autoconf` <mdupont>also try guix shell -D guix and guix install guix <jaft>pfna: I think just via the ~substitute*~ function, like with any other file editing. I was able to find just one instance of editing a =defaults.mk= file, in particular, in the repo.s: =efivar=, in =gnu/packages/linux.scm=. <jaft>They add a phase right after =unpack= to modify the file before any building or configuring starts in the later phases.