IRC channel logs
2024-11-12.log
back to list of logs
<jonsger>does someone now how long the Guix user survey runs/is open? <janneke>attila_lendvai: hehe, i just fixed that template for the 64bit hurd <ekaitz>jonsger: do it now so you don't have to worry about that :) ( futurile knows ) <divya>These builds will be the end of me :) <ekaitz>divya: a trick is not to pull from the remote until you finish :) <divya>I think I'll finish a few movies by the time this is done <Ironsmith>hummm i'm having trouble running `secrets` (gnu packages gnome secrets) it complains that it's missing the python module `pwquality` but i can see that module being installed via the dependency libpwquality@1.4.4 which i can see in my store. <Ironsmith>is this a bug with the package or my system? <Ironsmith>(i just installed it and did a few git pull and system reconfigure runs but that didn't fix it) <Ironsmith>i did install `secrets` via `guix install secrets` instead of adding it as a system-wide package, could that be why? <olafes>This is probably a silly question. Reading through the definition of grep's package I've came across this code: <olafes> #~#$(if (and (not (%current-target-system)) <olafes> (string=? (%current-system) "i586-gnu")) <apteryx>should bash-completion always be a native input ? <apteryx>is it purely used at build time of provides something (libraries) used by bash completion at run time^ <wakyct>Does anyone know if messages to bug-guix need be approved beyond the first one? I've sent just one before but the one I sent this morning isn't in the archive yet or at issues.guix.gnu.org <olafes>Is `package` just a helper for building derivations or does guix tread derivations built with `package` in some special way? <bdju>wakyct: yeah I think I've had messages get stopped/delayed before even after the first one <Rutherther>sneek, later tell olafes: it kinda does treat package in a special way. But the built derivation is treated the same. Packages have a lot of metadata, and also search paths. This allows tools like guix search to work. And also to install them reliably - some packages need search paths to function properly <vhns>Is there a way to define system containers/namespaces declaratively in Guix? <vhns>Say I want my wireguard and nginx running in a separate namespace from the system's default namespace <vhns>Thanks, I'll take a look. <Rutherther>vhns you will need to define the service yourself though, if you want to use it with already existing services that dont use containers. You can use record inheriting of the original, but it will work well only for leaf services <apteryx>wakyct: it's down to the humans doing the moderation <apteryx>typically they'd wait a few messages before trusting your email, as one legit email then spam has occured in the past <futurile>Good news we've hadd 391 responses to the Guix survey. And I've fixed my fubar on one of the questions. Slightly less good news - a lot of people aren't completing it / hitting the 'submit' button. <sepeth>futurile: I was mostly afk for the last week. Is it still up somewhere or am l late? ^-^ <futurile>sepeth: if you take it and it all works please tell me - as I had to take it 'offline' and then 'import' the answers again which was very scary <sepeth>futurile: Grabbing a cup of tea and on it. <futurile>sepeth: there better be a biscuit with that! <sepeth>futurile: Done. My computer restarted in between, so the first one probably will show not submitted on your side, but finished on the second round. <sepeth>It went well and quick, and I enjoyed the questions. Small suggestion for the next one, I think Alpine can be replaced with Debian for questions like foreign distro. IIRC, the former uses musl libc, and I think Debian is more popular around here. <attila_lendvai>mumi dies for me with no such file for ~/.mumi/current-issue. i don't have any ~/.mumi, even though i used mumi before. any hints? <futurile>sepeth: ah good point on the Debian thing! Thanks for taking it. <futurile>attila_lendvai: isn't there a command to switch it to a "current issue" <futurile>attila_lendvai: ah right, got it - well that's the limit of my knowledge of mumi <fnat>attila_lendvai: I also don't have '~/.mumi', but I do have a '.mumi' folder at the root of my Guix checkout. <rekado>attila_lendvai: are you running it from a git repository? <rekado>when I run "mumi current 123" in, say, /tmp I get an error because no git root directory is found. <rhuijzer>Hi, I want a newer neovim. I'm already using the updated package-definition privately. To update neovim in master I will need to update some inputs (eg. treesitter). Should I split this up in multiple patches or one big one? <KE0VVT>Failed to install Guix on Fedora Silverblue again. <rekado>rhuijzer: separate commits/patches. <futurile>rhuijzer: check issues and whereiseveryone for updates that other people have already done - sometimes you can avoid work that way ;-) <rhuijzer>futurile: where can i find 'whereiseveryone' ? What is it? <attila_lendvai>fnat, rekado, yep, that was the problem, thanks! it must be run from a guix checkout. i do have a .git/ in my ~/ which made the mumi error message not very useful. <futurile>rhuijzer: it searches configurations/channels that people have added - so sometimes you can find an updated package that someone has published on their own channel <aldum>that .minna TLD always surprises me <attila_lendvai>isn't it a bug that the nftables shepherd service doesn't contain a requirement for networking to be up? i deploy my server, and can't ssh to it until i herd restart nftables on it. <attila_lendvai>OTOH, maybe we want the firewall rules applied before the network is up... but then my question is the reverse. <attila_lendvai>and i still have no idea why a `herd restart nftables` is needed after a fresh reboot to connect through ssh <attila_lendvai>nor why my deny_4 set remains empty after the restart, while it immediately some gets entries after a reboot. something is wrong here... as if a herd restart nftables loaded a different ruleset <attila_lendvai>well, `nft list ruleset` does say the same after a herd restart (except some entries in the deny sets). but i cannot ssh in until i do a `herd restart nftables`. <attila_lendvai>my ip gets into the deny set when i try right after a reboot, and after a `herd restart nftables` the deny set remains empty (even though the printed ruleset seems to be the same) <attila_lendvai>hrm, this seems to be transient. after a while my ip doesn't get into the deny set anymore. it must be some weird nftables internal state when warming up... <nckx>wakyct: Once you've been ‘approved’, the only delays are those in the mail pipeline. Sometimes these can spike up to several hours. They're beyond our control. If your messages don't show up in the Web archives, there's probably nothing a human can do to speed them up. <nckx>(Even first submissions, yes.) <apteryx>clicking on links in weechat no longer opens them in librewolf <apteryx>it opens an empty librewolf window, and I have to manually paste the link in. <nutcase>apteryx: yesterday I observed a similar issue (opening links from emacs) after installing flatpak(-xdg-utils) into my home profile. I now moved it back to my system profile and opening links works again for me. To me, this seemed to be quite mystical, tbh. <Rutherther>nutcase flatpak Xdg utils work by utilizing portals to get the associated program. So you need to get portals running correctly to get flatpak Xdg utils give you correct programs <nutcase>Rutherther: yes, I have other xdg-portals running. What was mystic is, that non-flatpacked software was behaving strangely <Rutherther>nutcase flatpak-xdg-utils is not for flatpak. It is a replacement of Xdg utils with flatpak implementation of Xdg utils. Emacs uses Xdg-utils when they are available <rhuijzer>sepeth: thats roughly where I am now, thanks. Do you think you're going to finish that? I'm contemplating diving in but a lot of update patches aren't reviewed anyway <Rutherther>rhuijzer have you looked if the rust packages are updated on rust team branch? <rekado>I'd like to use Docker images (created with "guix pack") on AWS. Guix pack generated images contain a /gnu/store. Is there a way to use Guix commands (such as "guix shell") when the root file system is provided by a Docker image? <rekado>"guix pack" is really convenient for deploying software, but I worry that the resulting image is unusable as a Guix installation. <rekado>in fact, I'd like to use "guix system docker-image" to generate a more complex Docker image running system services. Will I be able to use Guix inside of these images? <janneke>attila_lendvai_: #71211 is (marked) not a bug <attila_lendvai_>janneke, i know, but i disagree. it was stopping me to debug something that failed early in the initrd, IIRC when i was hacking on shepherd. <attila_lendvai>janneke, at the very least it should print an error in the unimplemented or unsupported functions, not just segfault without any explanation <janneke>attila_lendvai: trying to load a readline that doesn't match guile is likely to segfault <attila_lendvai>it stopped me to debug my original issue, and it also wasted my time to find out why i couldn't get a repl... and then the bugreport was closed as not-a-bug. honestly, i find that kind rude. <janneke>someone would have to put some (serious) development into this to provide a matching readline <janneke>if you were to work on that, probably better to look into providing gash and gash-utils in the initial ramdisk instead <attila_lendvai>janneke, the root issue is that libc references remain in the static executable, and the assert for this is effectively disabled by calling remove-store-references <attila_lendvai>janneke, why not link just libreadline statically to the guile binary? <janneke>attila_lendvai: it wasn't just closed; the issue was investigated and an explanation was provided <janneke>attila_lendvai: readline cannot be linked to guile because of licensing issues <attila_lendvai>janneke, technically you're right, but... it still doesn't work and the behavior wasted my time. <janneke>attila_lendvai: i'm sorry if you experienced that as rude, i'm certain that was not the intention <janneke>attila_lendvai: yeah, that's terrible... <janneke>(both your wasting time and the licensing) <attila_lendvai>so, to sum it up: a store reference to libc remains in the guile-static binary, and it's zeroed out by remove-store-references, which leads to an opaque sigsegv, and in the initramfs context of all undebuggable places. <attila_lendvai>marking that as not-a-bug is strange to me. especially that the call to remove-store-references thwarts an assert that is in the code at a later point to catch this problem early. <janneke>attila_lendvai: like i said, the initrd situation is less than great and i'd love for someone to start adding gash and gash utils there <janneke>the segfault is unfortunate, but to be expected (not a bug) <attila_lendvai>janneke, but would gash help to get a backtrace from guile in case an exception escapes the error checking guards in shepherd? <attila_lendvai>or maybe not merely a backtrace, IIRC there was a useless one printed, but give a chance to look around in the debugger for futher info? <attila_lendvai>i don't want to sweat this too much, but an "expected segfault" is an oxymoron for me. but we can leave it at this... i don't have the authority around here to set standards. <janneke>well, the ux is terrible, on that i agree <rekado>when building a system image with "guix system docker-image", is there a way to install the current Guix? Is it enough to include current-guix in the packages field of the system declaration? <rhuijzer>sepeth: I've updated treesitter but I've had to update a sizable part of crates-io.scm. Updating & testing 20+- rust packages and creating some new ones, seperating them into patches, will be a lot of work with no guarantee that the patches will get reviewed <rhuijzer>Welp, nice exercise in packaging for me I guess <futurile>rhuijzer: are they based against rust-team branch? <futurile>rhuijzer: rust-team is about three back in the queue, so if you send them, there's probably time to look at them before it gets merged - 20 isn't too bad <rhuijzer>futurile: oh I shoud've done that probably, they're based against main <rhuijzer>futurile: If I migrate my changes to rust-team, do I have to do anyting special to git-send some patches? <rhuijzer>Nvm found the answer in the docs. I might look into it. Thanks <futurile>rhuijzer: no, not particularly. efraim is "the" rust team. So I generally cc him on my cover letter so he knows it's there, and the patch magic will add him to the other ones. <rhuijzer>futurile: Seems like i just redid the work that's already done in rust-team. I should've checked :) <futurile>rhuijzer: heh, oh well learning experience. With dev done on branches now it's happened to me a couple of times. <rhuijzer>futurile: yeah, sh*t happens. Thanks for helping, have a nice day <ieure>Does Guile have an equivalent of Clojure's comp fn? <dthompson>ieure: what does it do? compose two procedures? if so, try 'compose' <ieure>dthompson, Yes, ((comp a b) arg) => (a (b arg)) <dthompson>I'm having a number of problems with builds on the latest from master <dthompson>so far had failures building qemu and u-boot-tools <ieure>I semi-regularly get Cuirass builds that report "failed (dependency)." How can I determine what dependency caused the failure and why? There are no logs or other obvious information I can see. <ieure>I believe it's saying that one of the package inputs wasn't found or failed to build. But I can't fix that unless I know which one it was. <olafes>What's `computed-origin-method`? It's used in many packages, but it's scarcely mentioned anywhere, if at all. <sneek>Welcome back olafes, you have 1 message! <sneek>olafes, Rutherther says: it kinda does treat package in a special way. But the built derivation is treated the same. Packages have a lot of metadata, and also search paths. This allows tools like guix search to work. And also to install them reliably - some packages need search paths to function properly <nutcase>Rutherther: (xdg-utils) thanks for the explanation. So, when I had flatpak-xdg-utils in my home profile and xdg-profile in my system profile, flatpak-xdg-utils's xdg-open was used in favor of hte normal xdg-utils's xdg-open, right? <Rutherther>olafes: the function has a comment above its definition, it explains what it's for <nutcase>(used in favor depending on the order of my $PATH) <ieure>olafes, computed-origin-method lets you create dynamic origins for things you may not know the SHA of in advance. <Rutherther>nutcase: yes, home profile comes in front of system profile by default, so that's likely what was going on <nutcase>Rutherther: now I have both in my system profile. How is decided, to which one my /run/current-system/profile/bin/xdg-open links to? <olafes>Rutherther: right.. I didn't notice it's defined in guix/packages.scm <Rutherther>nutcase: that's conflicting files in a single profile, and in that case I am not completely sure, but it is likely the one that comes being the one winning the conflict, and thus ending up in the resulting profile. <nutcase>Rutherther: something like a race condition does not sound satisfying, I should resolve the conflict by myself then. Did I understand correctly, that I need flatpak-xdg-utils only in cases where I want xdg-open (or xdg-email) to open an application that is a flatpak app? If this is not the case, I don't need flatpak-xdg-utils at all, right? <Rutherther>nutcase: `guix shell xdg-utils flatpak-xdg-utils -- bash -c 'realpath $(which xdg-open)' -> flatpak-xdg-utils, guix shell flatpak-xdg-utils xdg-utils -- bash -c 'realpath $(which xdg-open)' -> xdg-utils <Rutherther>so I was wrong, it's the second one that wins the conflict it seems, at least given the conflict resolution function is the default one <Rutherther>nutcase: you do not need to have flatpak-xdg-utils for opening a flatpak app. To open any app, including flatpak ones, just make sure to have its desktop file in one of XDG_DATA_DIRS share/applications folder, and put name of the desktop file to mimeapps list <Rutherther>nutcase: flatpak-xdg-utils is useful mainly when you are in a container, like in a flatpak app, or guix shell container. But when you are in a flatpak app, the installed flatpak-xdg-utils shouldn't be available as far as I know, since it's running in a container that deliberately shadows your programs. So flatpak programs already should come with their own flatpak-xdg-utils for programs that can use it <nutcase>Rutherther: so I never need flatpak-xdg-utils in my system profile then? <nutcase>(provided my system itself is not running in a container) <icepic->Hey guix. Can someone do me a favor and check if `guix build --target=arm-linux-gnueabihf isc-dhcp` fails for them too with the current master? <Rutherther>icepic-: oh sorry I haven't read properly... :D I will try it and get back ot you <Rutherther>icepic-: yeah, I get errors. Specifically on dns/enumtype.h: no such file or directory <icepic->Okay. Same for me. Looks like the Gen binary which generates the missing header files during compilation is build for arm and not x64. Since it is executed during build, it will crash. Funny thing is that aarch64-linux-gnu works. <PotentialUser-34>hi, is there a way to get guix to pull to the revision that has completed a build farm run (so that substitutes are always available and I stand the best chance of avoiding a local compilation)? I just pulled and started building qemu locally (killed it and downgraded to an earlier revision). <PotentialUser-34>hm.. okay. I'm looking at ci.guix.gnu.org and am thinking good candidates would be revisions with completed test runs to do on a case by case basis <futurile>PotentialUser-34: the easiest way is to look at the build farm <futurile>PotentialUser-34: find the ones that shows 'revisions' between one and the next - so you know it's fully processed it <futurile>PotentialUser-34: then I put that into my channels.scm file <PotentialUser-34>futurile: not sure wym by 'revisions' between one and the next. I see checkmarks? <futurile>PotentialUser-34: about half way down the page it has an expander with 'compare' right? that one <futurile>PotentialUser-34: so I would use one which has that expander as it tells you it's finished processing and did the comparison. If you go earlier it might not be fully finished (I think that's how it works anyway) <lynn_sh>ty ieure is there any documentation that may help me figure out how to apply this to my current package? <lynn_sh>last question i remember there was a way to try and build the package locally but when i try guix build '(@@ (artoria packages education) anki-bin)' -L. it tells me the version is not available. <ieure>lynn_sh, Suggest `guix build -L. anki-bin' in the root of your channel. <ieure>That's how I manually build stuff in my channel. <Rutherther>also.. if you export it publicly you can just refer to it with its name with specification, what you've shown is useful for referencing non-exported symbols <jck>is there a good way to get time-machine like functionality inside of a manifest.scm for guix shell? Right now I'm doing something like guix time-machine -C channels.scm -- shell -f manifest.scm, but curious if I can do this all in my manifest a la a nix flake. <dthompson>I don't think it's possible right now but sounds feasible for someone to add <dthompson>introduce a type that wraps a manifest with the time machine info and add the necessary code so 'guix shell' knows what to do with it <Rutherther>jck: you can at least put shebang at top of the manifest so that when you execute the manifest it will call that command on itself <jck>how do you mean? place `#!$(which guix) time-machine -C channels.scm` at the top of the manifest? <jck>and that will get executed? for now I was imagining shipping a devshell.sh which executes that command I typed out in my initial message, but that feels a little sad. would be nice to mix and match packages from different hashes as well. <polyedre>Wow that's great! Is there already a deadline for the survey? Btw I found that the question in the survey were thoughtfully designed. <ArneBab>Is there a way to create a software bill of materials (sbom) from a package definition in Guix? Ideally in a way that allows it to be plugged into standard vulnerability checking tools. <ieure>ArneBab, I'm not aware of any, sounds like a potentially interesting project. <ieure>I don't think much of automated vuln scanners, though. <dthompson>those automated vuln scanners are terrible but if you've got compliance targets to hit I sympathize. <ieure>dthompson, I work in healthcare, so, yeah. We regularly get people freaking out because "this thing has a 9.8/10 CVE!" And then it's something like a denial of service in the library for in-memory data storage used by unit tests. <ieure>Could be worse, used to have yearly PCI audits when I worked in finance. <ArneBab>ieure: I like the scanners, because they get people to actually see CVE’s (though 90% of the time the answer is "not affected: an area we don’t use"). I just wish they were easy to use from Guix and for Guile. As it is right now, the sbom creation tools exclude smaller languages. <meaty>could somebody help me update the gzdoom fomula? it's like ten generations old <makx>5/7 CVE, would patch again <meaty>it seems the patch phase is acting up, saying the file it's supposed to patch is read-only