IRC channel logs
2024-12-09.log
back to list of logs
<vhns>is there a prebuilt wsl2-image-type guix image? <basicnpc>The "default" emacs I got from guix channel doesn't look at ~/.config/emacs/ ? <basicnpc>How should I change it so it looks at it upon starting? Or am I using the wrong way? <Jacobissimus>I think emacs will only look for ~/.config/emacs/ after trying ~/.emacs.el, ~/.emacs.d, ~/.emacs (sorry I missed the first part of what you said) <Jacobissimus>Looking in the manual it looks like the ~/.config/emacs location can be overridden by XDGCONFIGHOME, so if that is set somehow, maybe that's causing some confusion <unmush>graywolf: I expect the slowness is coming from recursive syntax transformers being used in the implementation <basicnpc>I'd like to use dwm as the main window manager for my guix system. However, it has to be recompiled again everytime I reconfigure it. So if I want to reconfigure, I don't want to get dwm from the default guix channel. What should I do? <basicnpc>Thanks! That means I need to first learn guix packaging anyways. <potatoespotatoes>silly question: how do I make a `define-public` that I can also reference from a sibling `define-public` definition? <unmush>top-level declarations within the same module should be visible by default <potatoespotatoes>a slightly bigger question: How do I reference a package's output filepath? <potatoespotatoes>specifically, I'm trying to get patches from one repo and apply it to another repo. <potatoespotatoes>I was trying to use assoc-ref, but it doesn't seem to work. Something like: (define-public foo ...) (define-public bar (package ... (origin (patches `(,(string-append (assoc-ref foo "out") "/0001.patch")))))) <unmush>I don't think it will work with conventional guix mechanisms to specify it directly in the patches list <unmush>well, now that I think about it, I do recall that it was possible to use an origin as a patch for another origin <unmush>which suggests a file-like-thing can probably be used <unmush>so maybe something like (origin (patches (list (file-append foo "/0001.patch"))))? <unmush>the problem is that the patches list is only evaluated at package-definition-time, so you need some declarative way of specifying the patch <unmush>another thing you could do is to use a snippet that invokes patch itself <potatoespotatoes>another option that I was attempting was to modify-phases with an `add-after 'unpack ...` and run patch directly, but I still wind up in trouble with my `(assoc-ref foo "out")` it always returns false <unmush>I think what you want in the phase is probably (assoc-ref native-inputs "foo") <unmush>assuming that you put the input package in question in native-inputs <unmush>you could also use #+(this-package-native-input "foo") <unmush>or just #+foo (but this means recursive package transformations won't reach foo) <Kolev>Is there a guide for setting up a GLAMP stack on Guix System? <Kolev>I'm wanting to deploy Known (withknown.com) on Guix System. <potatoespotatoes>ah, how do I import file-append ? I can't seem to find this documentation <potatoespotatoes>unmush: for the assoc-ref native-inputs suggestion, how do I reference native-inputs? guix is telling me that `native-inputs` is out of scope. <unmush>you change your procedure parameter list like so: (lambda* (#:key native-inputs #:allow-other-keys) ...) <unmush>also now that I think of it native-inputs the phase argument is only used during cross-compilation, so I think you actually want (assoc-ref (or native-inputs inputs) "foo") <unmush>(with a corresponding INPUTS also added after #:key) <apteryx>maybe it's been this way for some time, but I keep having to rebuild llvm working on python packages, which is annoying <podiki>apteryx: what do you mean? mesa has been built with llvm for quite some time <podiki>though in the past the version may have been different; and i guess python is in everything (directly in llvm, lots others from meson for instance) <efraim>I'll let you folk decide what to do about llvm and llvm-for-mesa. My use-case introducing it was to link against a smaller llvm (and decrease the closure size) and to not have to build full llvm on 32-bit powerpc <homo>is it really that bad? pinebooks for example have only mali gpus, is it revelevant to have llvm-for-mesa there that supports i915, radeon, amdgpu, etc. instead of only lima? <efraim>I figure it's better to support too many GPUs than too few. also llvm is needed for llvmpipe, the fallback renderer <homo>I mean do those GPUs even run on pinebooks? <efraim>i'll turn mine on and see what it says <homo>when building system for custom hardware like pinebooks, it's better to save resources by not building drivers for non-existing devices on that specific hardware <homo>I tried compiling full-blown llvm on amd64 several years ago and it was more resource hungry than compiling gtkwebkit, today it surely is hungrier because more GPUs appeared <efraim>glxinfo seems to suggest mali and opengl/gles 3.1 <efraim>I could see using transformations to replace the running mesa or qtbase or some other packages with smaller versions on the pinebookpro, but for the build farm I still think it's best to support the largest amount of hardware possible <homo>is it possible to split drivers in different packages so that building on pinebooks is not that difficult? <efraim>we'd end up with different dependency trees, based on which drivers were built. The idea of replacing the distro binary with a smaller version works with replacements, but the original one still needs to be built so all the other packages in the chain can also be built <efraim>it's not possible to only build some of the outputs of a package, we'd have to build all of it and then we could tell it to only use specific outputs later <homo>recently I had to limit -j to just 1, because otherwise compiling gtkwebkit eats all 8 GB RAM on my laptop, then I had to create swapfile because, surprise, linking kernel (vmlinuz) requires too much memory <jjba23>Hey everyone, I wanted to ask some help/clarification about Docker and Guix <jjba23>I love Guix and use it on all my machines as Guix system. <jjba23>I have found sometimes outdated packages and have tried my hand at updating then and contributing upstream successfully a couple times. <jjba23>Here is the thing, I need Docker for work, and I love how easy it is to setup in Guix, but we run a terribly outdated version, V20 , when v27 is out . Who could help with this? How much effort is it? Any blocker? <jjba23>This would really make my life easier, now I am finding myself editing work Docker files since my machine doesn't support the newest features. Thanks <jjba23>I hope and pray there are some people that could help in this effort to update Docker <jjba23>it's a bit too much for me on my own to comprehend <janneke>jjba23: you need help updating Docker at work, is that it? <jjba23>Hi janneke, I use Docker (mostly at work) for developing software. Guix packages contains v20 while most other package manager already are shipping v27 <jjba23>so I am outdated against my colleagues and it starts to lead to problems unfortunately <jjba23>in my config i added `(service docker-service-type)` and works nice, but as I mention, outdated version <janneke>jjba23: ah, docker is outdated in guix; is that guix pack --format=docker? <janneke>that's the only docker'y thing /me has used so far <jjba23>i am unsure about the `pack` functionality. I refer specifically to docker-cli, containerd and friends (also docker-compose) <jjba23>i looked in (gnu packages docker) module and tried some things but struggle to understand how to build these big projects <jjba23>do you have any idea how we could bring this up to date? any maintainers we could reach out to? or good-hearted people? :) <janneke>what i do in such cases, is [use magit blame to find where to] look at the previous commit that updated the package., in this case 0869b0e6a35851d17dd876fcd517eb8e7b017238 <janneke>well, this was a minor version bump... <jjba23>good tip! but indeed that was not immediately indicating this person knew a lot about docker <janneke>a few commits back is the 19->20 update: 185ae9b410a43f0415e83f9fb88549c21ca4a673 which might be more interesting to look at <jjba23>what would you suggest is a good course of action? also to raise awareness about this to interested people that might help <janneke>i would just start doing the obvious things, like updating %docker-version and see how far you get <janneke>maybe it "just works" and you can send a patch set <janneke>otherwise you run into a specific problem, you can also send a patch set asking for help with the specific problem you encountered <apteryx>jjba23: from what I recally, updating docker is not that difficult, because it cheats (bundles all of its go modules as source). <jjba23>thanks for your replies all ( janneke apteryx peanuts ) i will go down the rabbit hole, see if i can at least make a small start <janneke>wow rust-1.54 has been building for 2h -- on an 8 core machine <efraim>it takes about 45 minutes on my machine but I just timed out on my riscv64 machine after 1440 minutes because I forgot to disable the timeout :/ <janneke>ACTION obviously needs a new machine, or more time :) <jfred>ooh, and a new website too! built with haunt no less! <civodul>i have to prepare the package update in Guix <basicnpc>Then I logged into root via another tty, but the var is still not set. <basicnpc>Rutherther I want to set it for all users, including root. <Rutherther>you can't use home for setting something for all users, you need to use a system service <basicnpc>One major thing I want is to set PATH to include $HOME/.config/guix/current/bin/ <basicnpc>Rutherther So I'm using the wrong way..? <basicnpc>I just want to have that PATH set for each user upon they login. <Rutherther>yes, it's not the right way to use home services to do something system wide <basicnpc>I should do it user by user? What is the service name I should look into? <Rutherther>no, if you want to make it system wide, do not make it user by user, do it with a system service <Rutherther>specifically, session-environment-service-type is a system service for managing environment variables <Rutherther>it's unfortunately not in the manual, I looked for the name in the code <Rutherther>or just use what you arelady have, it has the same usage interface <basicnpc>Btw, why isn't ~?.config/guix/current/bin added into PATH by default in guix system? <basicnpc>Really? I was motivated to do this because everytime I opened up a shell I need to type `export PATH..` again. <Rutherther>you need to use a login shell to get stuff from profile, just opening a shell won't execute the profile script <Rutherther>ie. relogin to your session, or manually "bash --login" <basicnpc>Ok, session-environment-service-type worked as expected. <basicnpc>But I'm still confused.. before I do this, $PATH does not have anything about $HOME/.config/guix/current/bin <Rutherther>so the path $HOME/.config/guix/current exists and points to a guix profile? <basicnpc>Rutherther Yeah, that/current exists and it's working. <Rutherther>so if you "source /etc/profile", do you get it in path? <basicnpc>Wait... I got a feeling that that PATH is added when I wasn't noticed. <basicnpc>Why.. yesterday, indeed, I need to type that manually. <Rutherther>so then it doesn't make sense. Bash is supposed to source /etc/profile, as first thing it does, when used as login shell. So you must've not relogged since you got the profile <basicnpc>Perhaps yesterday /path/to/current didn't exist yet? So when I login it's not added correctly. <Rutherther>does bash started with --login flag give you that profile to path? <basicnpc>hang on.. i'm confused.. lemme undo what I did first. <basicnpc>Ok.. I undo what I did with the service, and confirm that ~/.config/guix/current/bin has already been added upon login. <basicnpc>Yesterday I didn't see this, and I guess perhaps it's because back then that dir did not exist when I login. <podiki>efraim: regarding llvm-for-mesa; we had some tweaks in the last mesa-updates, still is a bit smaller than full llvm if i remember [which I'm all for] but mesa keeps getting bigger <efraim>I need to make room in my SBC farm area for my ppc laptop so I can start building there again and making sure stuff still works <efraim>problem is the top of the freezer is only so big and the laptop is the size of like 3 or 4 boards <efraim>then I can finally test if mesa still works on 32-bit ppc <podiki>i have a few updates on mesa-updates branch <podiki>i need to do libva, but other than that i'm not aware of much pending <podiki>right now is wayland-protocols, libdrm, mesa <podiki>yeah i'll put in the request to merge today <podiki>ideally i guess we do that regularly on a separate branch <efraim>I think ludo tried to make that a separate job in cuirass, but I'm not sure how it's being processed <jfred>I've got a Honeycomb LX2 lying around that I really need to get around to setting up as a build server <podiki>efraim: security-updates job? or does that just build the actual packages and not dependents? <efraim>I think we might have some honeycombs in the build farm, so it should be a well documented platform if you do go with guix on it <podiki>so "direct dependents" just means those with these packages as input/native-input then? rather than the whole tree? <jfred>efraim: yeah, I ran across the build farm configuration at one point, should be a good starting point <podiki>I'll try to remember to email guix-devel tonight too then, see if we want to take some ungrafting on mesa-updates or do a branch <basicnpc>How did it work? How did it change the content of my home directory on the fly, and switch it back when I `exit`? <basicnpc>(It was a bit scary to see all of my other files gone in that container.. `pwd` tells me that I was in my home directory indeed.) <Rutherther>it didn't change them. It just runs inside of a separate linux namespace, that's what container usually refers to (ie. docker, podman containers...) <basicnpc>Did it do `chroot` some point in the procedure? <efraim>sometimes I feel like 'magic' is the correct answer <Rutherther>no, chroot and linux namespaces are distinct. linux namespaces supports more than chroot <efraim>failed to install 'C.UTF-8' locale: 22 <basicnpc>However, now I get an error: no `setup.py` found. <efraim>civodul: it didn't fail building the derivation, so it's probably ok... <basicnpc>And indeed, there's no setup.py. The installation of maestral is quite simple: `python3 -m pip install --upgrade maestral` in a suitable python env. <basicnpc>(Also, mit license isn't found in the module (guix licenses)..) <ieure>basicnpc, pyproject-build-system. <ieure>basicnpc, And the MIT license is "expat" in (guix licenses). <civodul>efraim: what is it you were building? <ieure>basicnpc, Older Python projects with setup.py need python-build-system, newer ones with pyproject.toml need pyproject-build-system. <ieure>basicnpc, There's a comment in licenses.scm. It is confusing IMO. <efraim>civodul: @ build-started /gnu/store/33cz7hgprdcm80lkaiyx6qcvzc0frx5m-make-4.4.1.tar.xz.drv - powerpc-linux /var/log/guix/drvs/33//cz7hgprdcm80lkaiyx6qcvzc0frx5m-make-4.4.1.tar.xz.drv.gz 2826 <ieure>basicnpc, "there's not just one 'MIT license'" basically. <basicnpc>Which module has pyproject-build-system? <ieure>basicnpc, (guix build-system pyproject) <basicnpc>ieure How did you find it? I couldn't find it in the doc. <ieure>basicnpc, It's in the manual. <basicnpc>Am I looking at the wrong one? pyproject- <efraim>I had to find the power cord and another ethernet cable <ieure>basicnpc, It's not in that part of the manual. I use the info manual with Emacs' reader, which has a nice search feature. `C-s pyproject RET', then hit C-s until I find the right bit. <ieure>basicnpc, I think info(1) lets you do this from a terminal, but I rarely use terminal software. <basicnpc>I see, so I need to sort of have seen 'pyproject' to start with. I guess that comes with time. <basicnpc>Now it's failing at sanity-check phase. Should I just modify that phase and skip it? <ieure>Figure out what it's complaining about and fix it. <ieure>basicnpc, The manual page you linked has a big red section about pyproject-build-system, "Note: Currently there are two different build systems for Python packages in Guix: python-build-system and pyproject-build-system." <basicnpc>`command "python" ... failed with status 1`, that's in the log <ieure>basicnpc, That's from the build system, scroll up or open the build log to read the error output from the python process. <ieure>It's `guix build' telling you some command failed, you need to read the output of the command which failed to see why. <basicnpc>Yep, I vimmed into the log and see that in the last few lines. <basicnpc>It's happening in the last two lines only. The last line says "build process 6 exited with status 256", and the last second line: command "python" "/gnu/store...sanity-check.py" "/gnu..site-packages" failed with status 1. <basicnpc>It doesn't tell me more why it failed with status 1. <ieure>basicnpc, The reason should be there if you scroll up. Feel free to pastebin the full build output and/or log ifyou need help finding it. <basicnpc>ACTION is struggling pasting the file.. as the machine is newly setup and `y` in vim doesn't actually put that to system register. <ieure> basicnpc, "...checking requirements: ERROR: maestral==1.9.4 DistributionNotFound(Requirement.parse('xattr'), {'maestral'})" <ieure>As I said, it's above the message you were looking at. <basicnpc>Lemme use the released git commit. Perhaps that's a bug. <ieure>basicnpc, It looks like a missing dependency in your inputs. <basicnpc>Oh! That's what it means. (Is this normal when you try building? You make a file, let it run, see how it fails, add missing parts, try again?) <ieure>basicnpc, I'd say this is normal for the majority of all software development. <Rutherther>basicnpc: that can take a lot of time. So if you can, rather look into the dependencies of the project, here to the pyproject.toml file <ieure>basicnpc, Are you building this package by hand, or did you use the PyPI importer? Guessing the former. <ieure>basicnpc, `guix import pypi maestral' will give you an autogenerated starting point. <ieure>basicnpc, And `guix import pypi --recursive maestral' will include definitions for dependencies of maestral not already ing Guix. Though it looks like it's getting confused by flake8. <ieure>basicnpc, did you start from nothing and type all the stuff yourself <basicnpc>I don't know what I'm doing. I have added 2 other dependencies. Now I'm stuck withthe dependency "survey<6.0,>=4.0". I don't know where to get it, still loking. <basicnpc>ieure I asked gpt to generate a starting file, and modified. <ieure>basicnpc, oh christ do not do that lmao <ieure>`guix import' is the tool you want. <basicnpc>Hmm, new thing to learn. So should I try `guix import pypi maestral`? <ieure>Yes. And since it's griping about flake8, use that to make definitions for any of the stuff maestral needs that lacks a Guix package. <basicnpc>WOW lol. How did it compute such a file so fast?!?!?! <ieure>It's a purpose-built tool that does some very simple stuff. <ieure>You'll still need to modify it a bit, but this is going to be much closer to right than anything else. <basicnpc>It gives me (homepage null), but then `build` complains that null is undefined. <ieure>basicnpc, Set it to the homepage. <ieure>The author didn't add it to the PyPI metadata, so the importer couldn't populate the field. <basicnpc>Ok, now.. python-desktop-notifier is an unbound variable. But i have used python-xyz and python-build already. <ieure>basicnpc, As I said, you'll have to import dependencies that aren't already packaged. This is that. <basicnpc>So, that means I have to package python-desktop-notifier as well? The same process of packaging python-maestral? <basicnpc>I commented 3 dependencies out for the time being. Will go packing them later. <basicnpc>I will be back after lunch.. Thanks for your help, ieure ! <basicnpc>which says pytest fails. I read up, and it seems to be that there's no tests ran. Perhaps it's because I commented out those three dependencies. <basicnpc>"python-desktop-notified", "python-pyro5", "python-survey" <basicnpc>ACTION will read log. Thanks for any help! Hopefully this time I can package this successfully. <graywolf>Hello :) When adding new configuration type, what is the policy regarding the documentation? Should I document all possible values or can I refer to the upstream documentation instead? <graywolf>I have a script I can use to convert the documentation into texinfo, but I wonder if there is a value in adding 15k+ lines of texinfo very few (if any) people will read. <graywolf>attila_lendvai: I have somewhat similar solution (utilizing hashmap), but I allow only specific values, since I want to perform validations on them. <graywolf>Using (define-configuration) sadly did not pan out, since (home-mpv-configuration) call took ~30 seconds even when passed just one field. <attila_lendvai>i think it only makes sense to replicate the config fields on the scheme side if there's actual smartness added. if it's just mirroring the values to the app, then it's just a waste of effort both at the author and the user side. <graywolf>I think being able to do #:alang '("jp" "en") is nicer then #:alang "jp,en", it will see what reviewers will have to say <attila_lendvai>if the added value is only the validation of the values, then i'm on the fence... i can be convinced either way <attila_lendvai>graywolf, if i'm a user, i'd prefer the same syntax as the app expects. the extra cognitive load has a cost. i think it's only justified if it gives back enough value. <graywolf>I just think that when some options have format like [W[xH]][+-x+-y][/WS], validatin during configuration time is nice <graywolf>Well luckily you can pick your poison, there is `extra-configuration' slot for arbitrary gexps <graywolf>But at that point (plain-file) would probably work well as well <attila_lendvai>depending on the context, it can be worth it, sure. i'm just warning not to forget accounting for the costs of the extra indirection. <graywolf>I am curious though, in what cases would you say it adds a lot of value? <attila_lendvai>graywolf, in my case the guix service supports running n number of service processes, and parts of the configuration gets "inherited" from a template, while the rest is generated (like listening ports, etc). i'd say this setup adds enough value to bear the cost of the added complexity on the lisp side. <attila_lendvai>basically any setup where using lisp to generate the config often comes handy. but then this is orthogonal to using hashtables to directly map config values to the app, so... <basicnpc>Hello folks! I'm trying to package python-maestral. There's an error when pytest is run (exit code 5: no tests collected). Instead of `guix build -f formula.scm`, how do I observe it step by step and have a better idea why no tests were performed? [build log: https://0x0.st/Xh_9.txt] <fnat>Sorry, I've been mentioning this around quite a bit (including on Guix Devel). I hope I'm not spamming too much. <Rutherther>basicnpc: does the thing you are packaging have any tests? <fnat>The assembly is meant as an umbrella space that can gather Lispers from all Lisp-related projects (including Guix!). <gabber>i seem to be unable to initially reconfigure my freshly installed Guix System, due to: "guix substitute: error: TLS error in procedure 'read_from_session_record_port': Error in the pull function. <gabber>guix system: error: `/gnu/store/<hash>-guix-1.4.0-27.1eead56/bin/guix substitute' died unexpectedly". am i doing something wrong? <gabber>i tried only pulling substitutes from ci.g.g.o (due to it happening when obtaining from bordeaux) but to no avail <ieure>gabber, You're not doing anything wrong, I don't know if this is a network thing, Scheme GnuTLS thing, or both, but that happens often. Just retry it. <gabber>ieure: thanks for the reassurance. i've been trying for about 10 times now. wish me luck (: <gabber>is it somehow related to the speed of the machine - cause that's the most obvious difference to my other installations <basicnpc>Oh! I found that there's a --keep-failed option :-) <basicnpc>So now I'm in the failed directory. Ran pytest, and it collects no test indeed :-( <basicnpc>Why is it looking at ./.hypothesis/examples instead of tests in ./tests/ ... :-( <basicnpc>I just found that there's no ./tests/ in the "keep-failed" directory! How could that be possible? <Rutherther>because pip downloaded stuff usually doesn't include tests, you need to use git <ieure>Yeah, the PyPI sdist probably doesn't have them. <ieure>You can use the Git source, or put #:tests? #f in the package arguments. <basicnpc>Resolved it by pointing the uri directly to its github repo. <basicnpc>Now it's asking me to set the env var HOME to user/home directory. <basicnpc>I went to the "keep-failed" folder, and see that the HOME (in the env-var.txt) is set to homelesshelter or something like that. <ieure>basicnpc, The build runs without a real $HOME. <basicnpc>That means I need to modify its expectation? <ieure>The homeless-shelter dir (wish it was not called that) is a r/o path that gets set by default, it makes some of the build failures where they want to write into $HOME more obviousl. <Rutherther>depends on what it uses the home for. You can also just make a temp folder and point HOME to it <basicnpc>In any case, the pytest suites seem unhappy that it's pointed to a fake home folder. <ieure>basicnpc, It's probably trying to do some stuff it ought not. <basicnpc>If I just make a temp folder, why should it be happier? <ieure>Because it can write to it. But you should probably figure out why it wants to write to $HOME and make it stop. <basicnpc>home_dir = get_home_dir() => RuntimeError: Please set the env var.. blah blah. <ieure>But why does it want the home dir? <basicnpc>(Wow, if I don't read python, then I can't package it at all.. Thank god I am literate enough to read python. But if this were Ruby, say, I'm baked.) <ieure>basicnpc, This is a bug in the code. <ieure>Yeah I'd just delete those tests honestly. <basicnpc>How do I delete the test in the guix build file?! modify-phase? <ieure>basicnpc, #:tests? #f, like I was saying before. <ieure>Well, that just makes the test phase do nothing. <basicnpc>I must have missed that! Ok, now I have the next error, complaining that 'survey' is missing. I guess I need to face the reality now and package survey... <basicnpc>Now packaging survey! I did remember to use guix import :-) But then it complains that /etc/ssl/certs/ca-certificates.crt is invalid path. <basicnpc>guix has that else where.. how should I inform the builder where it is? <ieure>basicnpc, Those are in the NSS_CERTS package, but they don't get put into /etc/ssl, you may need to do some path hackery. <basicnpc>I added nss-certs as native inputs, but it still the same. <csantosb>Someone else having "Invalid image type ‘webp’" when using emacs+mastodon.el, all handled by guix ? <basicnpc>ieure I put that into native-inputs. Where would nss-certs be installed during the building process? I don't see them in the keep-failed dir. <sneek>Welcome back civodul, you have 1 message! <sneek>civodul, mdj says: dthompson I applied my psyntax patch which temporarily reverts 7379049d3. <civodul>csantosb: i think the problem is that our ‘emacs’ package is built without libwebp support <csantosb>civodul: system-configuration-features, system-configuration-options ... ideed ! <csantosb>But it should, following the NEWS::Support for the WebP image format. <ieure>basicnpc, They don't get installed, really, they're in the store and the path is in inputs. <csantosb>I see, libwebp is missing in emacs packages ... 😥 <ieure>basicnpc, Take a look at the python-requests-next package for some prior art. <ieure>basicnpc, Looks like nss-certs-for test is what you watn. <basicnpc>Looks pretty complicated. But I will give it a try. <ieure>That's a very simple package. <basicnpc>Ah, it passed! Now I have packaged survey. <basicnpc>How should I hook the result to the main package (maestral)? <ieure>basicnpc, Put in the inputs. Though if you used the importer, it should already be there, you just need to put it in the same file as your other package. <basicnpc>The dependency is survey<6.0>=4.0, and what I packaged is survey 5.4.2. <ieure>bascht, It looks like it's finding version 0.0.0? <ieure>Maybe the version gets set as part of the build or something? <basicnpc>In the built directory, there's a folder survey-0.0.0.dist-info <ieure>That's why it's 0.0.0, it's trying to use the scm version but can't pick it up, or is missing setuptools-scm from the inputs. <ieure>So it builds 5.4.2, but declares it at 0.0.0. <basicnpc>Yeah.. so I need to package survey again. Lemme think how.. <ieure>Does that package use the Git repo for the source, or an sdist built from it? <basicnpc>I use the autogen stuff .. pypi-url .. etc. Lemme change it to github. <ieure>Odd that the sdist gets built in such a useless way. <basicnpc>I have changed it to git-reference. I used that commit which assigns to version 5.4.2. <ieure>But if you use the git repo and tell it to check out the tag corresponding to the release, the existing machinery ought to work. <ieure>Or maybe it won't, idk, a lot of build things want to run in detached HEAD state, which messes with a lot of Git tooling. <basicnpc>It worked! Indeed! Ok, now I need to package the next one, Pyro5>=5.10 <basicnpc>Progress! Yes! It's getting easier as problems repeat themselves. <basicnpc>A new error: setuptools-scm was unable to detect version of /tmp/guix...pyro5../source. <basicnpc>So it asks me to use the intact git repo. <basicnpc>As my current method may have thown that metadata away. <basicnpc>In particular, the keep-failed folder doesn't have a .git subdir! <ieure>I'd expect the source dir (inside the build dir) to keep the .git dire. <ieure>The keep dir is the build directory, the source is in a subdir. <basicnpc>gpt says guix git-fetch doesn't get .git because it wants to make sure the dep is correct <basicnpc>we certainly don't want to pull different stuff from the same build formula <rekado>basicnpc: we don't keep the .git directory for reproducibility reasons. <basicnpc>Lol, gpt knows a way to "fake" scm version, which worked. <ieure>It's also the second result for "setuptools fake scm version" in a traditional search engine. <basicnpc>Haha yeah, GPT is just a hallucinational search engine. <ieure>LLMs are unreliable programs that turn stolen into IP into wrong answers by killing the planet. <basicnpc>Yeah, shits have happened though. The law of increasing entropy. <mange>I don't really see what's appealing about a search engine that makes things up. <unmush>aye, a search engine that makes things up is clearly quite different from a search engine that shows you made-up things