<f1refly>Good Morning. I just tried to guix reconfigure my system, but it raidvsed that there's no match for some git object, seemingly while inspecting the guix repository in the store. Heres the log: https://paste.rs/Bwhzu.txt. Any ideas what the problem might be?
<avalos>I installed the Syncthing home service, but I can't access the web UI using `localhost:8384`.
<civodul>you can check with ‘netstat -tupla | grep LISTEN’ or similar to find out which ports are opened
<civodul>we should specify the port number in the doc though
<minima>hi, the docs recommend to run `make authenticate' after every `git pull' of the guix repo; hm... but if a corrupt version of the repo is received, i guess the Makefile could have been tampered with too?
<minima>shouldn't one rely on a tool/script that's installed in the system already?
<civodul>rekado: oops! not sure how to fix this, i have long forgotten about the process (which was mostly handled by olasd)
<Altadil>Hi, is guix system reconfigure broken on the latest guix ? I just guix pull-ed and can’t run it anymore (other commands seems to still work). I get a "Git error: object not found - no match for id (be5bec47f7942a5e4d2a30eadd9a6fa4c715e88b)"
<cbaines>f1refly, Altadil, what does guix describe say?
<cbaines>looks like there's been some code changes recently in guix/git.scm but I'm hoping the latest version works...
<ArneBab>rekado: oh — thank you! I forgot to generate the PDF.
<civodul>cbaines: i’m sorry i guess i messed up this review
<civodul>ArneBab: i think you might want to mention ‘guix refresh’ (which works in many/most cases) and ‘guix edit’ (to locate the package)
<cbaines>civodul, no worries, the thread looks a bit arduous
<minima>ArneBab: thanks for the howto! personally, that'll come in handy! may i ask if `guix shell -D guix -- guix shell gperf texinfo gettext perl -- ...' is the same as `guix shell gperf texinfo gettext perl -D guix -- ...'?
<rekado>it’s not the same. The former opens two nested shells, whereas the latter opens one subshell only
<blablabla>more specifically: should a web interface go to the default output or to the gui output
<zimoun>on the side “guix pull” and “guix time-machine”, the short commit ID handling is consistent. You said: « <civodul> also short commits are no longer handled [11:28] » But they are via tag-or-commit. And if something provides (commit . "abc123") then the match falls into _ and reference-available? returns #f which trigger remote-fetch.
<zimoun>So I do not understand what you are asking about short commit ID.
<ArneBab>minima: the latter looks better — I did not know that it actually works ☺
<zimoun>civodul: resolve-reference uses an heuristic to then run 'commit or 'tag. If the heuristic applies the path 'commit then ’object-lookup-prefix’ is conditionally uses for short commit ID, no?
<minima>ArneBab: i suppose this partly boils down to personal preferences, but yeah, the latter might be a bit more compact
<zimoun>civodul: how the case (commit . "1234") could arise? It cannot using “guix pull” and “guix time-machine”. So it is only possible via internals.
<zimoun>To be clear, (commit . "1234") is not handled by ’reference-available?’ and returns #f.
<zimoun>But that case could not be possible since the introduction of 'tag-or-commit. If internals are still using it, they need to be converted to (tag-or-commit . "1234") in order to be consistent with the rest, IMHO.
<blablabla>how can i build a specific output with 'guix build -f' ?
<zimoun>cbaines, false-if-git-not-found does not mean “Git was not found”, I assumed the same hence some confusion although the code was just above ;-) but it means Git returned GIT_ENOTFOUND which signals “Requested object could not be found“.
<ArneBab>zimoun: maybe it could be renamed to false-if-git-reports-not-found ?
<ArneBab>minima: I now added a footnote that this can be done in a single call.
<PotentialUser-91>Can I specify from which channel a package should be installed? I have two versions of python-furo, but only the guix main channel version is installed. I want to install the version from my own channel (also for packages that depend on that)
<rekado>PotentialUser-91: the easiest way to do this is to rename it and then use package transformations to replace ‘python-furo’ with ‘my-python-furo’
<rekado>in a manifest you can access your package variant by variable name, so the package name does not need to change
<apteryx>rekado: you seem to have applied nice optimizations to teams.scm; I just had one question when looking at it, which was could it have instead used (guix memoization) for memoizing the read calls.
<apteryx>ekaitz: I don't think that's related, although if you use arm-none-eabi-toolchain you'd be impacted since that's no longer possible with the series
<rekado>apteryx: do you mean the changes to committer.scm?
<rekado>civodul: I never saw AVR as a serious platform, to be honest, because it is so very limited. At least my targets are all so small that I can’t see any use in a generic target for anything more than a vanishingly small subset of packages.
<PotentialUser-43>Hello. I have a package, that I want to split into the base package and an additional data package. The base package contains code and some data. The data package should contain big size data. How can the base package find the location of big size data when installed?
<superkamiguru>Now, this no longer boots, and the only way I can get it to produce a bootable image is removing the efi file-system declaration and set the root fs to vda1, though this causes partition resizing issues when modifying the vm. Does anyone potentially have some feedback on how I am going about/a better way to approach generating a qemu vm?
<SusanTheNerd>So the issue is that without manually loading insmod lvm, insmod luks, insmod crytodisk and running cryptmount (hd0,gpt2) I can't boot without getting an error of device /gnu/store not found
<jackhill>hmmm, just commeted on a CC=gcc in a review. I wonder if we could add that to guix lint.
<jackhill>also, if anyone has feedback on what I wrote in https://issues.guix.gnu.org/66193#1 I'd love to hear it. Some things I find difficult in writing a review (as a non-committer) are setting the right tone (I'm trying to be helpful and not give a laundry list of todos!) and pointing on things that could be improved (which file should the package go in, description wordsmithing in this one) but for which I
<gnucode>ngraves: what software do you want to use with that license?
<antipode>sneek: later tell jackhill: about CC=gcc: that hypothetical linter stopped being hypothetical a month ago: https://issues.guix.gnu.org/65426! Though perhaps CC=gcc was used in a place the new linter can't detect yet.
<rekado>but I really just want to see those that are relevant for ‘guix system image’, not ‘guix system vm’
<antipode>rekado: idea: maybe separate "guix system --help" from "guix system image --help" from "guix system vm --help"?
<ngraves>gnucode It seems that the FSF has not enquired into this license yet, but it respects the four freedoms. It really is a simplified Expat / BSD license. I will package with this license, but please let me know if I should send an email to the FSF before that.
<antipode>Maybe, more concretely: move all option info that is not universal to all subcommands, to the subcommands. Or, somewhat different, move info that's specific to a subcommand to the subcommand.
<antipode>I don't know if that would be sufficient but it should help at least a little I think.
<gnucode>ngraves: It might be a good idea to email them sure. I'm not really on the guix leadership btw. I would send a patch and see what they say.
<avalos>It's even in the store, but ldd can't find it, and attempting to run the binary results in `No such file or directory`.
<antipode>Is this for a software you (1) compiled yourself (e.g. ./configure && make), (2) installed through Guix (e.g. guix shell, guix install, ...), (3) you downloaded a pre-compiled binary and are trying to make it run on Guix?
<antipode>Methods to fix whatever the problem is depend on whether it is (1), (2) or (3).
<avalos>Everything else is linked correctly, except libgcc_s.so.1
<antipode>I'm not very familiar with the specifics but it's stuff like patchelf and LD_LIBRARY_PATH you need to look into. Though if everything else is linked correctly, perhaps you did that already.
<antipode>Alternatively, if you have access to the sources (and it's not a dependency mess like Gradle or something), you can compile it on Guix which likely would avoid the libgcc_s.so.1 issue. Often, but certainly not always, compilation is relatively straightforward.