IRC channel logs
2024-10-10.log
back to list of logs
<fireking04>Hi, since CI is down, lsof-4.99.3 won't compile (thunar and cryptsetup dependency). Has anybody successfully gotten into a temporary workaround? <bavier>fireking04, does it build with `--no-substitutes`? <kimjetwav>I'm literally testing it now to see but it of course should. There's nothing the build farm does that individual guixen cannot. <PuercoPop>Is there a way to install install-program as a package? <AwesomeAdam54321>PuercoPop: It should be possible, you'd have to write a package for it though <AwesomeAdam54321>The 'build phase would have to call (installer-program) and output it to a file that will be installed <PuercoPop>AwesomeAdam54321: No, my goal is to get Guix working on a [Vultr] VPS from an ISO. <PuercoPop>The current ISO I made, boots but there is no disk. The disk, /dev/vda, is not formated. <PuercoPop>I was thinking of running the installer or at least part of as a first step towards getting a properly configured system. I have the openssh 'custom' configured. <PuercoPop>Ideally I would need a one time only service to format the disk according to a specifiction <mange>PuercoPop: I run a Vultr VPS which I'm pretty sure I installed using the installer to get a minimal SSH config up, and now I manage it with "guix deploy". <mange>To your question about install-program, I think "guix build -e '((@ (gnu installer) installer-program))'" should print the path to the installer program (after it builds, that is). <__cornflake__>Hi everyone, just wondering how y'all do polkit stuff on a window manager with guix? I'm struggling to use polkit-kde-agent on sway because I can't find it's "polkit-kde-authentication-agent-1" file. There's several files called that in the store, but idk which one is correct. What do y'all do for this/ <sneek>Welcome back __cornflake__, you have 1 message! <sneek>__cornflake__, Rutherther says: you don't have to use my repo as a channel. You can either copy the function where you need it or the whole file. For whole file, just add the folder you put it in to your load path (-L) and adapt name of the module <__cornflake__>for the record I've been trying to autostart the agent using my sway config file, since that's how I've done it on other WM's in the past <mange>Looking at the output of "guix build polkit-kde-agent", in lib/systemd/user/plasma-polkit-agent.service I'm seeing a reference to $(guix build polkit-kde-agent)/libexec/polkit-kde-authentication-agent-1 ? <mange>Oh, Guix build just prints the path to the output(s) of the build. So "guix build polkit-kde-agent" builds the package and tells you where to find the resulting files. <mange>If you install the package into a profile you can also find those files in the profile. If you're adding it as a package in Guix Home that would be ~/.guix-home/profile/libexec/polkit-kde-authentication-agent-1 <mange>If you're using "guix install" it would be ~/.guix-profile/libexec/polkit-kde-authentication-agent-1 <__cornflake__>I was using a long command string to try to find the file in the store <podiki>store paths will change, so you don't want to use those directly <podiki>if you guix installed a package then i would think that libexec path would be in your PATH, but might require a re-login to be seen everywhere <mange>I don't think libexec is usually added to PATH, is it? I thought that was a difference between libexec/ and bin/ <podiki>i guess those are meant to be launched by the DE? <podiki>i've been trying out lxpolkit (from lxsession) package as a standalone polkit agent <podiki>that is just in the bin/ directory so i can just call it from my wayland session startup <__cornflake__>I was kind of hesitant to use those since some WMs (hyprland) wikis recommend KDE's polkit agent, but I'll definitely check it out <__cornflake__>I don't like it when packages like that install a bunch of other junk I don't want <podiki>i hadn't seen that recommendation <podiki>m on hyprland but almost never need polkit anyway <podiki>i see polkit-kde-agent has an xdg autostart file, that is what should be used i would guess (or you can get the exec line from there to get what gets used) <kimjetwav>fireking04, bavier: yes, it does indeed build just with `--no-substitutes`. <dcunit3d>is there something going on with the substitute servers? it just keeps connecting to bordeaux & ci without downloading anything <dcunit3d>i tried leaving nonguix subs in, but it was looping <Franciman>yeah dcunit3d because ci.guix.gnu.org is down <Franciman>and iiuc bordeaux doesn't have what you need? <aadcg>is there an alternative to the following invocation: guix shell -D -f guix.scm -- bash -c 'env LD_LIBRARY_PATH="$GUIX_ENVIRONMENT/lib" sbcl'? <aadcg>I'm looking for an analog of Nix's shellhooks <futurile>aadcg: I don't know what shellhooks are honestly, but I can intuit and Guix doesn't have them. Your invocation is what's needed AFAIK <Rutherther>aadcg: where nix would use shell hooks, guix usually uses search paths. So you could make a dummy package with native-search-paths set to "/lib", and put that to your shell. <aadcg>Rutherther: could you clarify what do you mean by putting it to the shell? <Rutherther>aadcg: you put packages to the shell, so you put that package there as another in the list. <aadcg>Rutherther: that's clear now, thanks <futurile>aadcg: so if you did created a packaged 'my-package' in your guix.scm, then you guix shell would install that package <aadcg>futurile: yes, that's what I did <aadcg>I believe I tried the native-search-paths approach and failed but maybe I should try again <aadcg>why do I need native-search-paths instead of search-paths? <fnat>Hey futurile, morning, thanks for the help with #73655 yesterday evening. Unfortunately, as pointed out by jgart on the mailing list, the other dependency (xandikos) is also broken by the update (in a non trivial way). <fnat>It was still good exercise to go through the patch though! <futurile>fnat: ah that sucks, so seems like it wasn't a trivial update unfortunately. It's a great example of why we actually have to test even the easy ones <fnat>I thought it was going to be a simple one as the tests were passing... haha... <futurile>fnat: is it completely unfixable then, just going to take you down a rathole? <fnat>It seems that, ultimately, one would need to update python-dulwich, but that requires some new rust crates... <fnat>It's not unfixable, but it makes things quite more difficult. <fnat>I'm not even sure I was going to use ical2org.py anyway... <fnat>But I have a couple of other packages ready, that give ical2org on the assumption that python-icalendar gets updated. <fnat>So, as suggested by jgart, I was thinking of simply keeping icalendar v5 in my personal channel. <fnat>Do you know what the best practice is for package variants, i.e. whether I should name it python-icalendar-5 or something like that? <wingo>apparently being exploited in the wild. everyone should upgrade afaiu <futurile>fnat: people don't seem to rename things much from what I've seen. <janneke>ACTION tried to upgrade icecat yesterday but no substitutes were available yet <fnat>futurile: Ha, I see, that's fine, it makes it even simpler. Ty. <wingo>i think most all guix users use firefox, right? most via icecat <janneke>wingo: do you know if guix carries a firefox that suppors guile-hoot/gc types? <janneke>that's why i tried to upgrade yesterday... <efraim>janneke: probably not, we're still on the 115 ESR <futurile>nothing in nonguix - I wonder if they know about it <Rutherther>is there information on what versions are affected? seems that the mozilla page doesn't point to much <aadcg>Rutherther: can you help me with a little toy example regarding search paths? say we want to create an env with sqlite that exposes LD_LIBRARY_PATH. write a file with contents: (use-modules (guix packages) (gnu packages sqlite)) <aadcg>(package (inherit sqlite) (search-paths (list (search-path-specification (variable "LD_LIBRARY_PATH") (files (list "lib")))))). and then issue guix shell --search-paths. I expected that LD_LIBRARY_PATH would be there. what am I missnig? <janneke>civodul: the function , hack is pretty neat! <Rutherther>aadcg: that seems unnecessary. You do not need to put the search path to the package like that, make a separate package that will provide the search path. This is common in guix - ie. the python package provides PYTHONPATH, but it is python-{packages} that use it <aadcg>Rutherther: then it seems to me that it doesn't exactly mimic nix's shell hooks <Rutherther>I just used that where you usually use them in Nix, Guix solves it with search paths <aadcg>Rutherther: fair enough. my use case is that I need to expose such a env var <aadcg>I just demonstrated above that it doesn't <aadcg>my goal was to replace invocations such as "guix shell -D -f guix.scm -- bash -c 'env LD_LIBRARY_PATH="$GUIX_ENVIRONMENT/lib" sbcl'" via search-paths, but it is still unclear how to do it <Rutherther>yes your example doesn't work, that is because you used search-paths and not native-search-paths <aadcg>Rutherther: just tested it by replacing it by native-search-paths. guix shell --search-paths still doesn't set LD_LIBRARY_PATH <aadcg>I guess what you're saying is that I'd need to make transform sqlite, call it say my-sqlite, and then use my-sqlite in the package I'm defining at guix.scm <Rutherther>it does for me when not using -D. -D means get dependencies of the package you just made and since none of the dependencies had ld lib path native search path, nothing provides it <Rutherther>you put the search path to the sqlite package, so only if you had that sqlite package in the shell you would get the search path. <Rutherther>what I am saying from the beginning is that you do not need to override any package. Just make a new one and put that one to the shell. <futurile>do you have some actual source code aadcg, that you're trying to package? or are you literally just trying to avoid that guix shell invocation? <aadcg>Rutherther: ok, now it starts to make more sense... quite an odd idiom but I get the idea <aadcg>my goal is to call guix shell -D -f guix.scm -- bash -c 'sbcl' such that LD_LIBRARY_PATH would be set to $GUIX_ENVIRONMENT/lib <aadcg>my hope was that I could bake that logic within guix.scm <aadcg>sorry, I meant guix sheel -D -f guix.scm -- sbcl <aadcg>in other words, the sbcl process needs to see that LD_LIBRARY_PATH is set to the /lib directory of inputs such as sqlite or glib <aadcg>I have managed to go around the issue by tweaking cffi:*foreign-library-directories* (ignore this piece of info if you don't know Common Lisp) <futurile>so I guess you'll need to add Rutherther's fake package part to your nxyt package definition <Rutherther>aadcg: then the package that guix.scm provides would have to have an input that would provide the search path. But if your goal is to put it somewhere for other people, then it would provide ld library path for everyone, everywhere, and that doesn't seem good. The software that needs it should be wrapped with it <aadcg>Rutherther: the env shouldn't be exposed to the usual packaging purposes. it only makes sense to expose it for development purposes. <aadcg>in short, I get the idea, thanks to both of you again! <Rutherther>aadcg: right, but that's where search paths come short to shell hooks. Search paths get exposed to all profiles, not just a shell profile. So even if one guix installs it, they are going to end up with that variable <aadcg>Rutherther: exactly, all clear now! <aadcg>typically Guix patches the sources so that .so files are called by its absolute path <aadcg>while developing, it's comfier to set LD_LIBRARY_PATH or set cffi:*foreign-library-directories*. I've resorted to the latter and wonderer how it can be done with the former <aadcg>for the former case, the best best is: guix shell -D -f guix.scm -- bash -c 'env LD_LIBRARY_PATH="$GUIX_ENVIRONMENT/lib" sbcl' <efraim>futurile: I'm going over your stgit@2 patches now. About to start building them. Looks good so far <Rutherther>although I see librewolf has reached 131.0.2 version upstream so that means it's probably fixed there and could be just updated? <Franciman>can't wait to be back to guix. Sadly a very bad conjure happened. My pc is destroyed <Franciman>and ci.guix.gnu.org not working means that the i can't install guix on my other lappy in reasonable time <Rutherther>Franciman: have you tried bordeaux substitute? should have a lost of stuff on master <Franciman>Rutherther: uhm i had this beaviour: i did guix pull and it looped forever <Franciman>i thought it was because bordeaux didn't have the substitutes <Franciman>and so it tried to refresh ci.guix.gnu.org endlessly <Rutherther>you need to set via substitute urls to remove ci.guix <futurile>am enjoying my standing desk at the moment - but just noticed that I'm playing dance music and bopping around like an idiot - looked sideways and realised that people walking down the road can probably see this weird human jiggling about heh heh <efraim>I'm not sure what to say, other than I've heard that from others but I can't replicate it <sepeth>Hi Guix, anyway to force bordeaux to build rust for aarch64. I got unlucky second time building rust from 1.54 all the way up :') <sepeth>Meant to put a question mark there somewhere ^-^ <ekaitz>efraim: the funny part is that I removed the package and tried to update and it's still failing in lsof <cbaines>it was done as part of the core-updates merge literally 2 months ago, so this can't be something where it's behind either <cbaines>guix includes commands to check this as well, you can do guix weather --system=aarch64-linux rust <sepeth>cbaines: hmm, thanks. Strange it tries to build it then. I am running guix in the git repo via ./pre-inst-env guix install icecat --substitute-urls="https://bordeaux.guix.gnu.org". Now I just used system guix, and that didn't say it is going to build it (yet) \o/ Would ./pre-inst-env be causing this? <sepeth>If so, can I still tell it to prefer substitutes? <cbaines>pre-inst-env wouldn't cause this directly <cbaines>and there's no notion of "prefering" substitutes, either ones available and authorised, or it's not <cbaines>the only option is --fallback, which governs what to do if a substitute should be available, but fetching it failed <sepeth>The only other thing I did was guix pull. But I always assumed if I run from the repo, that kinda is the same thing. <cbaines>sepeth, that should be very similar at least <cbaines>the --no-grafts --dry-run options as well as guix weather should be helpful in giving a clearer picture to whether substitutes are available <sepeth>Hmm, just stopped guix install icecat before finishing, and tried the same command with ./pre-inst-env, it nows wants to build rust again. <sepeth>Oh, so sorry, my fault, I didn't realise my local changes caused it. Stashed my changes, now looks the same, and no more rust bootstrap. <sepeth>A lesson for me to contribute back if I workaround something for aarch64 ^-^ <sepeth> rust-1.77.1-cargo 5.5MiB 2.9MiB/s 00:02 ▕██████████████████▏ 100.0% <ekaitz>jonsger: thank you! let me take a look <ekaitz>efraim: in lsof one test fails, as jonsger shared <ekaitz>i think i'm going to disable that test for the time being <ekaitz>what should we do, disable the test or include the pr? <iqubic>I have a question about GNU Guix System. Is there any way I can see if the Guix System will run on my laptop? <Boo`>iqubic: The Guix System installer will tell you if your hardware likely has no available free firmware if you boot into it and start the TUI installation process. This is at the start of the installation process so nothing will have been changed at this point. <ekaitz>efraim: do I need to change the package version with a review or something if I'm just adding a patch? <ekaitz>patch sent, waiting for the bug id <ekaitz>looks like issues.guix.org is dead and that kills peanuts <ekaitz>efraim: bison is everywhere i hate that part of the bootstrapping <ekaitz>efraim: please take a look to #73733 <ekaitz>efraim: also I didn't bother to bootstrap bison but it happens to be possible to the source, live-boostrap people did it <ekaitz>they use another kind of mini-bison for it, i don't remember the name <pjals>Hello, is Guix supposed to be updating substitutes so much when installing? It has been updating substitutes for the past 10 minutes now. <ekaitz>pjals: hmm yes and no, there are some services down and that might affect you <efraim>oh, they use byacc. I should grab that and see if I can stick it in somewhere as necessary <civodul>bummer that we got no feedback from the MDC IT regarding berlin.guix <civodul>nckhexen: should “we” email info-guix? <pjals>Even using bordeaux.guix.gnu.org seems to be not working, which is really weird <fnat>Anyone knows if it's possible to run the Nextcloud all-in-one Docker image under Guix's docker-service-type? I understand that all-in-one (i.e. multi-container?) images need a special setup? <pjals>Oh nevermind seems like bordeaux started working, yay! <efraim>of course, if we regenerate the file then there's a race condition in the makefile <nckhexen>sneek: later tell civodul No objections from me, but I can't do it rn. I just joined here to ask whether you at least got my mail (did you ever get the node-129 password, by the way?). <newsincesun>hello all, I am having issues building lsof 4.99.3 while doing a system reconfigure. I saw in the irc logs a patch was made by ekaitz so I did a 'guix pull' and tried again and it still had the same issue. Looking at the build log it looks like it fails because the LTlock test fails which is a different test failure than the one in the <luca>What's a Change-Id in the guix repo? I see it was added to one of my commits, but I didn't add it myself <ieure>luca, It's added by the git hooks in the repo. <ieure>I think it's the parent commit ID or something like that. <ieure>Another case of tooling papering over gaps created by the email patch flow. <luca>Ah I see. Similar to b4 probably <luca>I don't envy the people packaging software for guix <dcunit3d>luca, rust is a bit tough from what i've heard, but for me, writing packages and reading the source for the build systems has been a great way to learn <dcunit3d>did you use `guix import` for those commits? <Rutherther>Did you use guix import to create the package declarations?* <luca>I used vim and good old copy paste mostly <luca>So guix import can write those declerations for me, huh <luca>Good to know for next time <dcunit3d>also, if you have vim set up to evaluate guile scheme code, it's pretty great. <luca>Nothing more than color syntax and paranthesis colors <dcunit3d>i'm not sure what tooling vim has for scheme, but i'm sure it can do it <luca>So now that I've build this, how do I install it? <dcunit3d>well i would run `guix build -L $loadpath --keep-failed` with maybe some other options to see if it builds right <Rutherther>luca if you already know the command to build it you should be able to just replace build with install <dcunit3d>if it does, you can add a profile that contains the package. you'll probably want it with the other window manager packages. i think with sway, you can just try running it <luca>Well right now I am building inside `guix shell -D guix --pure --network`, would `./pre-inst-env guix install` install it outside the environment? <Rutherther>luca of course. As long as you dont use a container <luca>Ok, so now having tested this do I just send an email? (or would if the lists were up) <Rutherther>luca yeah, or in this case multiple, each for a commit (first one should be a cover letter to create the issue, then followup s to that issue address). e-mail handling should be unaffected by outage in Berlin. <luca>Does the commit order matter? And could I generate the Change-Ids again? Some commits don't have them <Rutherther>luca here is a section in manual for sending multiple patches. The only thing that is important with order is being able to apply each commit on top of another cleanly, all the way to current master. Reordering without caution can cause conflicts <Rutherther>If you want to reorder them, probably for the best to do it with git rebasing to make sure you won't miss anything <luca>I'm mostly asking in case the order of commits matter with the order of dependencies. If A depends on B, can the A commit come before B? But if it doesn't matter then I'll leave it mostly alone <plasma41>Well, the topic answered the question I was going to ask. Good luck with restoring ci and issues. <Rutherther>luca yeah. That is what I meant. Not sure about the order you are asking for <dcunit3d>luca: i would generate a patch based on multiple commits or squash the commits in your branch and create a patch for a single commit. <dcunit3d>have you already sent something in to the mailing list? <luca>I assumed the correct way would be one commit per package change, but I am open to anything the maintainers want <luca>Yeah, I figured. Usually I prefer `neomutt -H`, but I've never sent a series of patches, so this is probably as good of a time as any to set up git-send-mail properly <ekaitz>newsincesun: i did a fix but not in that test... <dcunit3d>luca: just read through chapter 22 in the manual, it's the same chapter that Rutherther linked to. it explains how to lint/test and then submit a patch <dcunit3d>the patch just needs to be sent as an attachment afaik, so neomutt would work <Rutherther>It should be sent in the format git format-patches / send-email does, not as attachment <ekaitz>Rutherther: you can do both, the one you prefer <ekaitz>format-patch and then attachment is ok too <dcunit3d>neomutt is probably what you want to use after generating a patch with git, though git-send-email i think integrates better for me (i'm an emacs user though) <luca>Yeah git format-patch && neomutt -H works just fine for one commit, but I doubt it will work for a series. Especially if it's 17 it might get tiresome <ekaitz>now upower doesn't build in my machine <ekaitz>oh now it built... it's only failing when I want it to build hehe <acrow>Those surprise, failed builds are always annoying... <gabber>i get this error when configuring a system's file system with a UUID i get this error. https://paste.debian.net/1331910/ any ideas what i am doing wrong? i got the value from `tune2fs -l /dev/sda1`'s Filesystem UUID field <newsincesun>ekaitz: ahh okay yeah on btrfs, thats probably it, thanks for that info, to be honest I am completely out of my depths so I will probably just wait for ci to go back up, but thanks for looking into it <ekaitz>newsincesun: no problem! we'll see if that can be fixed upstream <dcunit3d>ekaitz newsincesun yeh for guix pull, my system is trying to build mes using bordeaux, but it just kinda gets stuck <dcunit3d>i'm running guix build on it without upgrade to see if it fails <ekaitz>is it stuck or just taking long? <dcunit3d>i haven't pulled on this computer in a few weeks. some of the configure scripts that are running for gash seem to be missing a few tools (like `od`), so i was also getting warnings about performance. <dcunit3d>the process tree was changing every few minutes, but it would run for over an hour <dcunit3d>my build daemon is configured for 6 jobs & 8 cores, but not all builds are parallelizable <ekaitz>i detected some deadlock in riscv but it might be affecting x86_64 too <ekaitz>what I experienced was a sudden drop in CPU usage <dcunit3d>yeh, i'm hoping that by forcing a manual build, it will jiggle something loose <ekaitz>that was a Gash bug, gash maintainers are working on it, but I don't know if your issue is exactly the same <dcunit3d>do you know if mes requires building previous versions? the `guix pull` seemed to be building it multiple times before getting stuck <ekaitz>idk it was probably bootstrapping it <dcunit3d>so would it do that if bootstrapping? my intuition was that it may, but idk for sure. <gabber>dcunit3d: what command did you invoke? <ekaitz>there are different mes' in guix, the boostrapping one and another one that is a public package <ekaitz>you can find one in commencement.scm and the other in mes.scm if I'm not mistaken <dcunit3d>but for mes, just `guix build --keep-failed mes` <ekaitz>that mes is the package, not the boostrapped <ekaitz>in the pull you might be building the boostrapping one instead <dcunit3d>k, now that i think about it, when it pulls, it's probably getting many new versions of packages, including mes & the bootstrap mes, so this `guix build` may not work <dcunit3d>for some reason, it talks to bordeaux repeatedly, but doesn't seem to download anything <dcunit3d>i need to be running `guix pull` from a systemd service on this system ... but i've been planning to move away from arch for a long time (to fedora or something) ... so i'm missing quite a few automations like that <dcunit3d>it's much better to be current. i may wait until ci.guix.gnu.org is back online <dcunit3d>my guix system installation upgraded fine a few days ago <dcunit3d>well thanks for the feedback. i wish i knew more about the internals of everything <gabber>huh, i get the same error when trying with file-system-label instead of uuid. is there a proven-to-work `guix deploy` machine.scm file floating around? <sneek>Welcome back civodul, you have 1 message! <sneek>civodul, nckhexen says: No objections from me, but I can't do it rn. I just joined here to ask whether you at least got my mail (did you ever get the node-129 password, by the way?). <civodul>nckhexen: i got your message on guix-sysadmin, yes <ekaitz>civodul: any idea of how can someone get a guile patch reviewed <civodul>i’m one of the committers so i can do it <civodul>but i’m also trying to get other things done and i haven’t been good at keeping track of things in Guile <ekaitz>i did try to discuss the thing in guile people was not specially welcoming <civodul>(and yes, i know how frustrating that is) <ekaitz>i don't want to involve you specifically on this <ekaitz>i just want to understand what's the dynamics there <civodul>lately rlb has been doing nice work there <civodul>but yeah, there’s really 1.5 people looking at the patch queue, possibly infrequently… <civodul>i might get to your patch eventually if it’s in Debbugs, but i prefer not to make promises <ekaitz>civodul: i'd like to help, but there's a problem: it needs some dedication in people to get them involved <ekaitz>if there's no people, it's hard to include more <ekaitz>we are too guile-dependent to let it be in the status it is... <civodul>i’ve tried to break out of the circle, but i think i lack steam myself <ffupdate>is anyone working on updating librewolf currently? The latest RCE has me concerned. <ekaitz>civodul: you are quite busy already, it's not your reponsibility to do everything <dthompson>civodul: guile could really use someone who isn't you or wingo that can triage, merge easy patches, and dispatch more complicated ones to you two <ekaitz>dthompson: I agree, also working on the stdlib is quite easy, maybe not the internals of the compiler, but that can be done by almost anyone <civodul>dthompson: yes, agreed (that’s what i meant by “break out of the circle”: help volunteers to be in a position where they can do this) <ffupdate>Just checked the mailing archive for my question, seems that someone is working on a patch set to update librewolf. Hope it gets merged soon enough! <ekaitz>ffupdate: any knowledge about icecat? <dthompson>as long as I've been around I'm still kinda fearful to patch guile itself because even simple patches tend to have unexpected consequences that aren't caught with automated testing <ekaitz>dthompson: yeah... I also ported the JIT to riscv and passes all the tests -> but segfaults :) <civodul>i think most patches are about libraries: POSIX interfaces in libguile, the web modules, etc. <dthompson>if I may be so bold, guile could really use a third maintainer that was really into "developer experience" <daviid>mark h. weaver did offer to comer back as a guile maintainer, that would be awsome (if he still wishes) <ffupdate>ekaitz, just checked icecat's version, I think it's up to date with the latest icecat upstream: <ffupdate>idk if that includes the CVE or not (mixed up RCE and CVE in my last message, sorry!), so you may have to do some digging. <adaNewb1234>hi! I've just recently started using guix, as a secondary/tertiary package manager on a devuan system. I see that the errors I'm getting today for guix pull originate from ci.{...} being down, are there any workarounds? <adaNewb1234>I'm pretty sure I only have lagrange directly installed, but I might be misremembering. is there an equivalent of flatpak list? <ffupdate>adaNewb1234: IIRC the ci.guix.gnu.org servers are done, there's a command line argument, --no-substitutes, that you can add to most commands to disregard them, though you will be building stuff from source in most cases if you use that. <vagrantc>if bordeaux is still running you should still be able to get some substitutes <ffupdate>I think there's another CI server you can use by running your command as `guix pull --substitute-urls=https://guix.bordeaux.inria.fr`. That should work temporarily. I would look into adding another substitute server as your default for guix incase one goes down. <vagrantc>by default bordeaux is enabled out of the box ... <adaNewb1234>so, how much does it need to build if I use no substitutes? <gabber>vagrantc: yes, but if you pass --no-substitutes it will use none - with the option as stated it will use **only** bordeaux.g.g.o <ffupdate>depends on what you're pulling, but you should be able to use the bordeaux substitute server instead. <adaNewb1234>so, wait, what exactly does guix pull do? I thought it just updated guix itself, and maybe the package list(s) or equivalent. <ieure>Note that "update Guix" doesn't mean "upgrade packages installed by Guix." <dcunit3d>adaNewb1234: it pulls the new code, checks that signatures on commits match one of the PGP keys in the keychain branch, ingests the source, calculates a derivation and then runs a build on a new profile. (i may be mincing some terminology there or missing some details) <adaNewb1234>just rereading the --help pages... is there any difference between guix package -u and guix upgrade? oh wait, it says it right there. it's an alias <luca>Regarding `guix lint` I see that it tries to make contact with ci.guix.gnu.org (probably, since there are a lot of network errors). Should I wait until tomorrow and run the command again? Or is it probably not too important <dcunit3d>you don't need to run a full channel to use guix while adding your own package definitions though. the process for doing that requires some planning. <dcunit3d>i just add `-L $guileloadpath` to commands like `guix pull` and `guix system` <dcunit3d>then i maintain my own package definitions in a git repository <dcunit3d>they have a mastadon that you can follow for more information <adaNewb1234>what does "corrupt input while restoring archive from socket" mean? it was expecting a tarball but got html, or something like that? <dcunit3d>this happens occasionally, but one of the goals is a software supply chain (more or less) that can build almost everything from source. i'm not sure what level of connectivity with GNU's guix services at Bordeaux & ci are required to update guix. <dcunit3d>i don't think they are, per se. so as long as you can fetch from git.savannah.gnu.org (and git repos for other trees), then you can build packages <ieure>dcunit3d, `guix pull' doesn't work at all if savannah.gnu.org is down, which is frequently is. <ieure>That's where the Git repo hosting the Guix channel is hosted from, and where `guix pull' gets the new code from. <adaNewb1234>ok, so specifying that it should use bordeaux, it realises it has to build ibus. why doesn't this happen by default? <ieure>adaNewb1234, Why doesn't what happen by default? <Rutherther>hey ieure are you planning on updating librewolf to 131.0.2 since there is a firefox vulnerability. Or is there already patch for this version? <adaNewb1234>at least, that's what my not-familiar-with-guix-terminology eyes think is going on <dcunit3d>is that because ci.guix.gnu.org is down and bordeaux doesn't have a substitute that's specified by the derivation? <adaNewb1234>looks like it, but why does it not fall back to building in this state? <ieure>Rutherther, Yes, will be working on that update tonight. <Rutherther>ieure: I think nonguix is saying Firefox 131 doesn't have desktop file anymore, so this could be the same for librewolf I suppose? <dcunit3d>idk, but my intuition says it's the "corrupt input restoring archive from socket" <dcunit3d>adaNewb1234: try with `guix upgrade --verbosity=4 --keep-failed` <ieure>Rutherther, It's always something. The LW release only landed yesterday evening, I generally wait for upstream over pulling patches forward. Expect progress soon. <adaNewb1234>it is currently building, but if it fails again, I will keep that in mind, thanks dcunit3d <ieure>Rutherther, If you're raring to go, feel free to work on a patch and I'll be happy to leave review (but I can't commit). <dcunit3d>--keep-failed should output the path of a log file, but it may require some tracing <Rutherther>ieure: I will go to sleep soon, so I can't work on it now <ieure>Rutherther, Alright. Well, hopefully will have a path up this evening. <dcunit3d>emacs and emacs-guix help quite a bit. it's pretty simple to set up using a guix profile and `emacs --init-directory $HOME/.emacs.guix`. early on, i found those tools to be very helpful for learning terminology, looking at profiles and checking out items in /gnu/store. <dcunit3d>if you're not comfortable with emacs, then it may be a bit much at first. it has a `guix-build-log-mode` that can be used without setting up `guix-devel-mode`. <dcunit3d>otherwise, you have to `gunzip` the log i think. <vagrantc>i'd use zless or something that dynmically can decompress the log rather than doing so manually <adaNewb1234>ok, so now it's failing with building lagrange. guix itself seems to work fine, it's just lagrange's package spec needs updating or something. <vagrantc>newsincesun: the weird part is it should know it fails to connect to ci.guix.gnu.org ... so unless it is caching some old data from ci.guix.gnu.org ... it shuld have no idea if ci.guix.gnu.org has it or not <vagrantc>and typically it doesn't get that kind of informtion from the substitute server until it tries to actually connect to the substitute server ... <adaNewb1234>other than a git blame, is there a way to find out who's in charge of maintaining/packaging a given guix package? <ieure>adaNewb1234, Guix doesn't really have package maintainers the way other distros do, anyone can update any package. <ieure>Blame is probably the best way to find whoever has expertise in a particular package or if you have a question about a particular thing in one. <adaNewb1234>ah, so if I manage to work out how to get the build to work, I can just submit a patch? <vagrantc>yeah, although might not hurt to CC relevent teams or past contributors <ieure>Yes, it would be polite to do that. <ekaitz>i have an inferior I want to remove the tests from, how can I do that? <dcunit3d>yes, but there are considerations for packages deeper in the dependency tree. i haven't contributed much, but i tend to try to solve things on my own while considering whether it's beneficial or practical to contribute it back. it's been a good way to learn build systems <dcunit3d>it doesn't hurt to submit the patch anyways <krascovict>ok, I'll wait... I need to install the packages and I can't because ci.guix.gnu.org is down <krascovict>error message: replacement of /gnu/store/7nssmps9lw1ka00dqakzjscax6vyxmyz-module-import-compiled failed <ekaitz>krascovict: you should be able to install packages anyway <ekaitz>krascovict: that's part of the same problem of the ci <krascovict>ok, I'll wait for the systems to get up and running