IRC channel logs
2024-07-30.log
back to list of logs
<nikolar>so i want to package a project, and its build system is basically cp config && make <nikolar>what's the most appropriate build-system for taht <lfam>nikolar: I would use gnu-build-system and remove unused phases as necessary <sneek>Welcome back lfam, you have 1 message! <sneek>lfam, bdju says: thanks again! "wfetch" works now, also my api key started working so I can actually use it now. <nikolar>might be useful to have a "shell-system" where you just specify a shell command <lfam>Yeah perhaps. I wonder how many packages are like yours <lfam>It would basically be an variant of gnu-build-system, which many other Guix build systems are based on <nikolar>to be fair there's make, make check, make install i'd need <nikolar>hm how do i replace the configure phase with the cp config <lfam>There are other weird phases that are desirable in Guix. I'd link to the code but the Git server is currently offline <lfam>I'll use my ooooold mirror on Github <lfam>It replaced the configure phase <lfam>There are several examples in that file, some are using the old style, but easy enough to adapt, especially if you ask for help here ;) <lfam>Yeah, invoke runs shell commands and handles errors appropriately <lfam>I gotta AFK, be around later <nikolar>for reference, i am trying to package harec and hare <nikolar>there was some way to basically sed a file to replace a path in it, no? <jfred>I've been having trouble applying my home configuration from my other machines to my new aarch64 laptops. It seems like some of the packages I use aren't building on aarch64. What does "Failed (Dependency)" here mean? https://ci.guix.gnu.org/build/5240862/details <jfred>Just that some of the package's dependencies haven't yet been built? <nikolar>jfred: i got a pinebook pro recently and came across the same issue <nikolar>one of the dependencies of ffmpeg has been stuck in "scheduled" for about 50 days <nikolar>i think there's an issue with aarch64 build <nikolar>if i may ask, what aarch64 laptops do you have :P <jfred>MNT Reforms, both big and little haha (just got the Pocket recently) <jfred>I have a NUC in the basement that I've tried to build my home configuration on via qemu, but several packages are failing to build there too... having a bit of trouble working out which ones, it's been a bit since I've dived into guix this much <jfred>so I do wonder how much of it is build servers being behind and how much is actual build failure <nikolar>i tried to install ffmpeg, and when i saw a rust package building i just noped <nikolar>no way i am building rust on a pinebook lol <jfred>I let the pocket reform try to build some rust stuff overnight but when it wasn't done by the next time I needed to use the laptop I was like... nah, running builds on my server instead <jfred>Intel something. qemu-binfmt-service-type is very cool I gotta say (though I dunno what the overhead is on that) <nikolar>binfmt is basically 0 overhead, but qemu on the other hand :P <jfred>yep that's the one. I get that and the imx8mq mixed up sometimes (that's what the big reform shipped with) <jfred>I do have a honeycomb lx2 I've been meaning to try to get guix system running on, but haven't gotten around to that <jfred>would probably be a better build server for this thing than my NUC <jfred>it's got 8gb of ram though which is nice <nikolar>btw is there a way to get more output from building a package <nikolar>now i only get that it failed in configure <jfred>are you building the package through `guix build` or something else like `guix home reconfigure`? `guix build` I think shows you everything on stdout <jfred>and if that doesn't show you what you need, "guix build -f" should work on the same file I think <nikolar>is there a way to get the current platform <nikolar>i just need to get aarch64 on arm and x86_64 on x86 <nikolar>when the target is arm or x86 that is <iyzsong>nikolar: to get the current platform, use (%current-system) from (guix utils). (%current-target-system) is for the target, which returns '#f' when not cross building. <nikolar>i need the target system, so when cross building to arm i need arm <nikolar>why does (%current-target-system) return $f when cross building <iyzsong>nikolar: it should return 'aarch64-linux-gnu' when called in the build side (eg: as #$(%current-target-system) in a gexp phase) <iyzsong>how did you build it? 'guix build PKG' or 'guix build --target=TARGET PKG' <iyzsong>okay, the pattern is to use "(or (%current-target-system) (%current-system))", which handle both cases. <nikolar>#$(or (%current-target-system) (%current-system)) <nikolar>btw how do i cut a string in scheme heh <jaft_r>nikolar: like a substring? Or matching by regexp.? <nikolar>basically i want the start of the string up to a delimiter <nikolar>the docs are down and i don't know where string-split is :( <jaft_r>In either case, – assuming a variable of ~str~ – you could do something like ~(substring str 0 (string-index str #\-))~. <jaft_r>(assuming "-" is the delimiter you want; sub. as needed) <jaft_r>If you prefered "string-split", then ~(car (string-split str #\-))~ would work. <freakingpenguin>nikolar: mount-cifs in (gnu build file-systems) shows an example of using string-match to split apart a string by regex, although unless your delimiter is multiple characters there are simpler alternatives. <weary-traveler>when packaging scripts in guix, do the inputs corresponding to the shebang interpreters and/or other CLI utilities need to be specified in "inputs"? the build-system being used is the copy-build-system fwiw <weary-traveler>i suppose i can try it and see what works, but i'm hoping to gain some understanding/intuition on when to use inputs <iyzsong>weary-traveler: yes, it's implemented as 'patch-source-shebangs' and 'patch-shebangs' phases of gnu-build-system, which copy-build-system based upon. In the patch-shebangs phase, it search interpreters in 'PATH', which contains inputs directories (done by set-paths phase from gnu-build-system). <weary-traveler>iyzsong: thank you for responding. to confirm that i'm understanding you correctly. 1. adding the interpreters to inputs is necessary. 2. you were able to ascertain that by reviewing the code for the patch-shebangs phase of the gnu-build-system which copy-build-system inherits. did i understand you correctly? <weary-traveler>i see. the meaning of "inputs" depends on how the build-system in question does with it (to an extent). that is constructive <iyzsong>also 'patch-shebangs' phase only consider 'inputs' but not 'native-inputs', since when doing cross building 'native-inputs' are in PATH but we want the results use target interpreters... <weary-traveler>the trouble i've had is between inputs vs propagated-inputs. though it seems latter is mostly for libraries. but next time i'm in doubt i'll take a moment to review the code for the build-system since at the end of the day that's the code that runs <iyzsong>sure, my understand is that propagated-inputs are 'inputs' and at the same time 'propagated', when consider a leaf package A (not for packages depend upon that one) 'inputs' and 'propagated-inputs' are the same thing. when consider a package B, which has an input of 'A', it will also have 'inputs' from A's 'propagted-inputs' thus 'propagated'. <weary-traveler>but since patch-shebangs and patch-source-shebangs replaces references with store entries, that shouldn't be needed in the case when A is a collection of scripts. okay, that makes sense <iyzsong>yes, that's right, hardcoded references like shebang and rpath for libraries don't needed to be propagated. <iyzsong>weary-traveler: i think the license should be 'gpl3+' as their code said, and the 'description' could explain what those scripts do. otherwise looks good to me. <weary-traveler>iyzsong: good catch. the license is gpl 3. but the readme and the scripts themselves note "any version later" <fnat>rekado: Hi, following up on some advice you gave me a few days ago. I was able to set up my DLNA service which is great. Thank you! <fnat>I still have some issues with multicast over WireGuard though, which I understand is a bit of a known pain point. <fnat>My VLC client connects to the DLNA service when within the LAN but not via the VPN. I think the issue is multicast. May I ask if there's anything else that you do to route multicast over WireGuard, other than setting the interface as 'multicast on'? <maybe-mekeor>when i run a go-built program, i get "error while loading shared libraries: libgcc_s.so.1: cannot open shared object file: No such file or directory". any idea what i'm missing? <maybe-mekeor>with "go-built program", i mean, when a program i manually built with "go build" <nikolar>so a question, i am writing 2 package definitions, one package depends on the other <nikolar>how do i get the variable for the first package then to put into the inputs of the otehr <maybe-mekeor>nikolar: (define-public foo ...) (define-public bar (package ... (inputs (list foo)))) <nikolar>what if i am not working with modules <maybe-mekeor>nikolar: what i told you does not depend on "working with modules" <maybe-mekeor>nikolar: do you use -f? i.e. use files that evaluate to a package? <nikolar>also another question, one of the packages uses ~/.cache which causes it to fail with `Permission denied`, what's the correct solution to that <maybe-mekeor>nikolar: (define-public foo ...) (define-public bar (package ... (inputs (list foo)))) bar <maybe-mekeor>at build time, i'd prefer to patch it so that it does not use ~/.cache <nikolar>the problem is that it's using the same binary, to run tests and such <nikolar>so you can't just patch it at build time <nikolar>oh i might be able to temporarily overwrite it with an environment variable <nikolar>do those persist inbetween build stages? <nikolar>wait, how can i even define an environment variable inside of a package definition <maybe-mekeor>i wonder if my problem is because of libgcc_s.so.1 having wrong file permissions <nikolar>so i have two questions, in build time, is there are temprorary directory i could use that i have write permissions to <nikolar>and how can i set environoment variables withing gnu-build-system <fnat>I've been advised to use '(string-append (search-input-file inputs "/bin/CMD") "OPTIONS")' instead of '(string-append (assoc-ref inputs "PACKAGE") "/bin/CMD OPTIONS")'. <fnat>I can and should ask the person who provided that piece of advice of course but is there anyone who knows why the former is better than the latter?