IRC channel logs

2024-10-10.log

back to list of logs

<Guest79>or where/who to ask?
<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.
<kimjetwav>Maybe there's some donky issue though.
<bavier>kimjetwav, thanks
<PuercoPop>The installer sets up the login-program for a tty to be the the return value of install-program. https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/system/install.scm#n351
<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
<AwesomeAdam54321>Is this for testing the installer?
<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
<__cornflake__>so that's why I'm trying to find its file
<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 ?
<__cornflake__>hm, this works. I don't know why, but thanks!
<__cornflake__>I'll have to look up what the output of guix build means
<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.
<__cornflake__>oh okay thanks
<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__>oh great, thanks! Yeah, I just guix install'd it
<__cornflake__>I've been meaning to set up Guix Home but I haven't yet
<__cornflake__>thank you so much, this is perfect
<__cornflake__>I was using a long command string to try to find the file in the store
<__cornflake__>and it wasn't working
<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>ah yeah you might be right
<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__>guix is really cool :D
<__cornflake__>oops lmao
<podiki>sure is :)
<__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
<__cornflake__>like gnome-tweaks installs nautilus
<__cornflake__>now I have 2 file managers :|
<podiki>i hadn't seen that recommendation
<podiki>i'
<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`.
<civodul>Hello Guix!
<user_oreloznog>Hello !
<dcunit3d>is there something going on with the substitute servers? it just keeps connecting to bordeaux & ci without downloading anything
<dcunit3d>ah i see.
<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?
<Franciman>i had the same behaviour
<futurile>morning :-)
<Franciman>hi futurile
<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
<aadcg>futurile: I see, thanks
<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
<futurile>oh heh
<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>True!
<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>RCE in firefox https://www.mozilla.org/en-US/security/advisories/mfsa2024-51/#CVE-2024-9680
<wingo>apparently being exploited in the wild. everyone should upgrade afaiu
<futurile>eep
<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
<janneke>we don't have firefox, right?
<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>sure
<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
<jonsger>futurile: I got aware now
<Rutherther>is there information on what versions are affected? seems that the mozilla page doesn't point to much
<futurile>jonsger: ah great heh
<janneke>efraim: right, hmm
<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!
<janneke>re https://toot.aquilenet.fr/@civodul/113265446306011291
<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 never said it mimics them
<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
<Rutherther>but it will expose it...
<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?
<Rutherther> https://paste.debian.net/1331846/ ie. this package. Then guix shell -D sqlite -f /path/to/this/file.scm
<aadcg>Rutherther: ok, now it starts to make more sense... quite an odd idiom but I get the idea
<aadcg>futurile: yes, see https://github.com/atlas-engineer/nyxt/blob/master/guix.scm
<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'
<wingo>for icecat, we could apply https://hg.mozilla.org/releases/mozilla-release/rev/d2a21d941ed5a73a37b3446caa4a49e74ffe854b
<Rutherther>I suppose this could also work for librewolf?
<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
<Franciman>lol
<Rutherther>Franciman: have you tried bordeaux substitute? should have a lost of stuff on master
<efraim>there's still https://bordeaux.guix.gnu.org and the one in Memphis
<Franciman>Rutherther: uhm i had this beaviour: i did guix pull and it looped forever
<Franciman>updating substitutes
<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
<efraim> --substitute-urls="https://bordeaux.guix.gnu.org"
<Franciman>oh bonanza
<Franciman>thanks
<futurile>efraim: ah cool - thanks
<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
<fnat>:)
<ekaitz>efraim: i have issues with lsof
<ekaitz>it doesn't build
<efraim>on master?
<ekaitz>yep
<efraim>I'm not sure what to say, other than I've heard that from others but I can't replicate it
<ekaitz>4.99 is the problem
<ekaitz>i had 4.94 installed
<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
<ekaitz>:)
<cbaines>sepeth, bordeaux has build rust for aarch64 https://data.guix.gnu.org/revision/f5aff5b3972b9a3342b1ce807f7ed68289cce74d/package/rust/1.77.1?locale=en_US.UTF-8
<cbaines>it doesn't need forcing
<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.
<jonsger>ekaitz, efraim: I have seen it on "my" build server. See the end o the logs https://cuirass.nonguix.org/build/9023/log/raw
<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%
<sepeth>Beautiful ^-^
<ekaitz>jonsger: thank you! let me take a look
<ekaitz>efraim: in lsof one test fails, as jonsger shared
<ekaitz>but the error is nonsense
<ekaitz>i think i'm going to disable that test for the time being
<ekaitz>efraim & jonsger this is the problem: https://github.com/lsof-org/lsof/issues/317
<ekaitz>what should we do, disable the test or include the pr?
<ekaitz>the change is not huge, btw
<ekaitz>maybe add it with a patch...
<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.
<iqubic>I see. That's good to know
<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>#73733
<ekaitz>peanuts: do your thing come on
<peanuts>ekaitz: Hi, for comments please contact my maintainers at https://codeberg.org/lechner/irc-helper-bot
<janneke>#73733
<ekaitz>looks like issues.guix.org is dead and that kills peanuts
<peanuts>ekaitz: Hi, for comments please contact my maintainers at https://codeberg.org/lechner/irc-helper-bot
<ekaitz>ACTION is sad
<efraim>oh no! mawk needs bison!
<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?
<ekaitz>efraim: yes! that was it yeah
<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!
<ekaitz>pjals: \o/
<ekaitz>efraim: thanks!
<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?).
<sneek>Got it.
<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
<newsincesun>cuirass.nonguix.org build log that was mentioned here previously.  Here is the test portion of the build log, the whole thing was too large for paste.debian: https://paste.debian.net/1331901/
<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>It only took 16-17 commits but I managed to build swayrbar https://git.lucamatei.com/guix.git/log/?h=user/luca/swayrbar
<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?
<luca>uhh, what?
<luca>I used git add -p
<dcunit3d> https://guix.gnu.org/manual/en/html_node/Invoking-guix-import.html
<dcunit3d>it's better than chat gpt probably
<Rutherther>Did you use guix import to create the package declarations?*
<luca>I used vim and good old copy paste mostly
<Rutherther>That must've taken a lot of work then
<luca>So guix import can write those declerations for me, huh
<luca>Good to know for next time
<dcunit3d>sometimes
<dcunit3d>also, if you have vim set up to evaluate guile scheme code, it's pretty great.
<dcunit3d>that was a blocker for me early on
<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>Cool, thanks
<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
<luca>I assume the section in the manual you were thinking of was https://guix.gnu.org/manual/devel/en/html_node/Sending-a-Patch-Series.html ? In that case I'll read it now
<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>Nope, never
<luca>I assumed the correct way would be one commit per package change, but I am open to anything the maintainers want
<dcunit3d>well in the future, you may want to look into https://git-scm.com/docs/git-send-email, but it requires some setup & awareness over how it stores authentication
<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
<ekaitz>newsincesun: are you in brtfs?
<ekaitz>newsincesun: https://github.com/lsof-org/lsof/issues/152
<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
<dcunit3d>woops...
<ekaitz>Rutherther: you can do both, the one you prefer
<ekaitz>format-patch and then attachment is ok too
<ekaitz>(afaik)
<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>anyone can replicate?
<ekaitz>oh now it built... it's only failing when I want it to build hehe
<Rutherther>Do you know what the error was before?
<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>dcunit3d: in what platform?
<dcunit3d>x86_64, amd
<ekaitz>hm!
<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>well, it gets stuck using one core
<ekaitz>CPU usage drops?
<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
<ekaitz>and the build got stuck forever
<dcunit3d>yeh, i'm hoping that by forcing a manual build, it will jiggle something loose
<ekaitz>until it was killed
<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>`guix pull -L $__ellipsis_channel --verbosity="${verbosity:-1}" --channels=$HOME/.config/guix/base-channels.scm --substitute-urls="$__substitute_urls" $@` via a bin script: `update-channels --substitute-urls "https://bordeaux.guix.gnu.org https://substitutes.nonguix.org"`
<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?
<civodul>gabber: hi! yes, there’s: https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/hydra/deploy-honeycomb.scm
<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>and https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/hydra/berlin-nodes.scm
<civodul>nckhexen: i got your message on guix-sysadmin, yes
<civodul>the password, i don’t remember :-)
<gabber>civodul: thank you!
<civodul>yw!
<ekaitz>civodul: any idea of how can someone get a guile patch reviewed
<civodul>ekaitz: did you ask on #guile?
<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
<civodul>so it’s best to ask there
<ekaitz>i did try to discuss the thing in guile people was not specially welcoming
<civodul>(and yes, i know how frustrating that is)
<civodul>oh, ok
<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
<ekaitz>oh that's useful
<ekaitz>i'll ping
<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
<civodul>ACTION nods
<ekaitz>we are too guile-dependent to let it be in the status it is...
<civodul>i agree
<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!
<ffupdate> https://lists.gnu.org/archive/html/guix-patches/2024-09/msg01532.html
<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"
<civodul>oh sure
<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> https://git.savannah.gnu.org/cgit/gnuzilla.git
<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.
<ekaitz>ffupdate: thank you
<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?
<civodul>adaNewb1234: hi! could you paste on https://past.debian.net the errors you got?
<civodul>er, https://paste.debian.net
<civodul>i would expect mere warnings
<adaNewb1234> https://paste.debian.net/1331919/
<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
<vagrantc>or pass --substitute-urls='https://bordeaux.guix.gnu.org' to exclude ci.guix.gnu.org ...
<gabber>i just stated `--substitute-urls=http://bordeaux.guix.gnu.org` to still get substitutes and ignore ci.g.g.o
<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.
<gabber>jinx
<vagrantc>by default bordeaux is enabled out of the box ...
<vagrantc>for some years now...
<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.
<gabber>adaNewb1234: yes, exactly this
<adaNewb1234>so, what else *can* I be pulling?
<gabber>other channels
<ieure>Note that "update Guix" doesn't mean "upgrade packages installed by Guix."
<adaNewb1234>ah, right.
<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>adaNewb1234: this explains more about running a guix channel. that overlaps a lot with your question https://write.trees.st/juliana/setting-up-a-guix-channel
<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
<adaNewb1234>btw, is it known why ci and issues are down?
<dcunit3d>sections 6.5 Guix pull, 6.6 guix time-machine and 8.5 guix authenticate describe the process more completely https://guix.gnu.org/manual/en/guix.html#Invoking-guix-pull
<dcunit3d>chapter 7 on channels is useful as well
<dcunit3d>basically everything is a derivation though. 9.8 and 9.9 explain more https://guix.gnu.org/manual/en/guix.html#The-Store
<dcunit3d>they have a mastadon that you can follow for more information
<adaNewb1234>hah! https://paste.debian.net/1331922 Something's still borked!
<dcunit3d> ithttps://hostux.social/@fsfstatus
<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?
<vagrantc>sadly https://cuirass.genenetwork.org/ seems busy not doing anything
<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>When I guix upgrade, I get the error message in https://paste.debian.net/1331922/. when I add --substitute-urls='https://bordeaux.guix.gnu.org', it realises it can't use a substitute for ibus, and starts building it.
<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
<dcunit3d>file-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.
<newsincesun>abaNewb1234: https://guix.gnu.org/manual/devel/en/guix.html#Substitution-Failure   I think when using just bordeaux it knows that bordeaux doesn't have the substitute so tries to build it but when using ci.guix.gnu.org it knows it does have the substitute but it can't connect so without --fallback it will fail,  but I could be way off as I am
<newsincesun>very new to guix
<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.
<vagrantc>there is etc/teams.scm
<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.
<dcunit3d> https://guix.gnu.org/manual/en/html_node/Teams.html
<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>hi...Is the ci.guix.gnu.org repository down?
<krascovict>Unable to access https://ci.guix.gnu.org/.
<ekaitz>krascovict: yes
<ekaitz>krascovict: also issues.*
<krascovict>Is there a forecast for returning to normal?
<ekaitz>krascovict: not that I know of
<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
<krascovict>ekaitz, I will try to install it again
<krascovict>I'm setting up docker
<ekaitz>it will take longer
<adaNewb1234>try with --fallback.
<krascovict>I am going to try
<krascovict>the error loops using the flag --fallback
<krascovict>the error loops using the flag
<krascovict>I think I got it here
<adaNewb1234>also try --substitute-urls='https://bordeaux.guix.gnu.org'
<krascovict>ok
<krascovict>I managed to install it, thanks to everyone
<krascovict>Unable to access https://issues.guix.gnu.org/67493.
<ekaitz>krascovict: that's part of the same problem of the ci
<ekaitz>the whole issues thing is down
<ieure>Has been down for days.
<krascovict>ok, I'll wait for the systems to get up and running