IRC channel logs
2025-03-19.log
back to list of logs
<ieure>dthompson, Thanks, that works. <ieure>Okay... what's an easy way to test this system service I want to contribute? `guix shell' in the repo doesn't work, because no sudo; `sudo guix system reconfigure -L/path/to/guix/clone' doesn't work because -L doesn't work at all with a Guix repo clone. <ieure>Copy the whole file into a different dir and use -L? <ieure>I don't really want to use a whole VM. <cancername>hmmm... I'm running `guix system init`, but t doesn't seem to be using substitutes <ieure>Okay, #77106 if anyone else is interested in having an autofs service. <ieure>It is not ready to merge, but is ready for people to tell me in more detail what should happen to make it so. <ulfvonbe`>re: issue notifications, I think it could be good to adjust it to report status changes (newly-opened, reopened, closed, etc) as it does now, but to batch simple "new message added" type updates together. So for example, every hour it might inform us of all the bugs with new messages that it hasn't already reported earlier. This way a back-and-forth that has 4 emails in 1 hour can be summarized as just "4 new messages in issue #xyz", <ulfvonbe`>and active conversations are much less likely to be interrupted solely by new messages <coyotes4ys>hi, wakyct jA_cOp if you're around, i guix home reconfigure'd with this .scm but no sound in vlc. then i thought i needed to maybe install a pipewire package, but after doing that, same. tried aplay as well and no soundcards found <coyotes4ys>does anyone know, if aplay finds no soundcard, and i try pipewire service and package (i added the use-module and service in the .scm), is there any tweak i am not doing? i am not getting any sound still. is it just deadend because nonfree blob? <coyotes4ys>how do i remove sof? diffiehellman told me it appears to contain several proprietary programs for intel sound hardware <ieure>coyotes4ys, ALSA is the stuff that talks to the sound hardware on Linux. If ALSA can't find a card, you get no audio. Both pipewire and pulse talk to ALSA, so none of that stuff will make a difference. <ieure>coyotes4ys, sof-firmware isn't packaged in Guix, because it's full of proprietary blobs (as you note). So there's nothing to remove unless you added it yourself, in which case, you presumably know how to undo whatever you did to cause it to install. <coyotes4ys>ieure- that's the weird thing, i really have no memory of installing it <coyotes4ys>ok i guess i need to get a new laptop agaaaaaain <ieure>coyotes4ys, Definitely do some research, but would eBay ThinkPad is always a good choice. Or you can go with a Framework or XPS (or whatever they're calling them these days). All those should have reasonable out of the box support. <ieure>(excluding wackadoodle ThinkPad models like the X1 Fold) <ieure>coyotes4ys, It depends on the model, I think from the 9370 (~2018) on they started soldering the WiFi, and no OEMs ship blobless WiFi. <ieure>As I have opined before, there simply does not exist any system which can run 100% Free Software and be usable. <ieure>The BIOS is non-free. The embedded controller (EC) or platform controller is non-free. The CPUs have a second CPU embedded in them which runs non-free software. You just have to decide what your own tolerance is. <ieure>The Freeest system you can swing is something like a T480 with Libreboot and an ath9k WiFi card. <ieure>That will still contain, and run, non-free software which you cannot do anything about. <oriansj>ieure: well circuits in one's computer are not generally something we can audit either. But libre-hardware may provide a solution to that (it is just hard to find enough hardare developers who are willing to help on a collective project) <oriansj>most libre-hardware ends up being designed by one person and doesn't bother to make sure it'll integrate with any other libre-hardware <oriansj>Otherwise someone couldn't compiled a full Linux computer from bits on opencores <ieure>oriansj, I don't see how open hardware has any bearing here. Open hardware designs can run non-free software, just like closed designs can run non-free. That's an orthogonal issue. <oriansj>ieure: if we build our own hardware, then there are no blobs. Only source code that we built ourselves <oriansj>thus we could run computers free of non-free software (in the bios, microcode, embedded controllers, etc) <ieure>oriansj, I don't care to argue at this time, but I disagree with you. And it's all hypothetical, since that hardware doesn't currently exist. <ieure>Def. would be nice to run a fully Free RISC-V system, but, nothing like that out there. <ieure>And I when it comes to things that use regulated RF, I don't see how you can build that in a Free way. <oriansj>ieure: didn't know you; hypothetical, impossible futures are the things I like to solve <oriansj>once bootstrapping guix from hex was only a hypothetical impossible future. <oriansj>it only takes 3-5 people willing to work to do it <oriansj>out of billions of people, we only need to find a handful <oriansj>sure, it might take a decade but who cares <ieure>I appreciate your optimism, and while I would like that future, I have seen no evidence that it will 1) arrive 2) be sustainable over the long term. <ieure>I have been using computers daily for nigh four decades and things have only gotten more closed. <oriansj>ieure: who cares? It only matters if a handful of people find it fun and interesting <emacsomancer>I seem to be getting a "Fontconfig error: No writable cache directories" error trying to run `mpv` on Guix. <oriansj>we don't need to be the ones selling shit, we need only figure out how to make it and let someone else deal with the mass production, support and selling parts. <oriansj>the problem is finding more people who are interested in that work. Personally once the 701C keyboard mechanism is available, my thoughts is use that as a base framework to stick a libre-hardware system in. <copernicus>are there known issues about fcixt5 not working with librewolf under sway? I've set the environment variables via `guix home` and they appear properly set when echoed, but librewolf doesn't reflect current IME settings as a native package (it does work as intended in a Flatpak) <oriansj>emacsomancer: yeah, finding the pieces is growing harder by the day too (too little centralization and cooperation) <emacsomancer>what makes up a typical computer becomes more complicated over time. and there's all of these things..... (e.g., GPU firmware; embedded controller firmware; the firmware in your SSD/HDD; SATA controller firmware; NIC (ethernet firmware); CPU microcode; USB controller firmware; WWAN firmware - assuming you've got Linux or whatever as your OS and your BIOS with Libreboot or the like) <oriansj>emacsomancer: well there is internal complexity (which is definitely prone to go up as you make things faster) But I would argue that HyperTransport is much simpler than Socket 8's FSB specification. <oriansj>The interconnection of the pieces can get simpler and more robust (while also getting faster) <RavenJoad>Is it possible to write "larger" tests for an individual package in Guix? I'm packaging a compiler right now and there are some tests I want to run on the installed version of the binary after it is built. Ideally, it would be possible to Guix-script this. <RavenJoad>How do people deal with GCC not expanding the crt1.o and crti.o paths when linking stuff? (This is a tool that calls out to GCC and I'm trying to wrap it up in a decent way to avoid propagated inputs). crtbegin.o is expanded correctly, but not the others. <RavenJoad>gcc-toolchain, gcc, and glibc are in the linker search path (c++ -L...), so they should be visible. <RavenJoad>If I look at ld's LIBRARY_PATH, there is a glibc entry in there that points to a version that has the crt files that are claimed to be missing. <RavenJoad>Ok, for some reason, adding -B/gnu/store/...-gcc-toolchain/lib to the g++ invocation fixed it. But I figured gcc-toolchain could figure out where all of itself was all the time. Isn't that the point of having a full toolchain package? <efraim>TIL void-linux has patches for node on ppc <apteryx>it also registers the latest 1.4 release <apteryx>hm, that's curious: error: Unable to read directory '/etc/qemu/firmware': Cannot allocate memory <apteryx>in a VM test. I guess I need to augment its available memory? <apteryx>yep, happier with 512 MiB instead of 256 MiB <lactose>What causes the screen to dim while idle on i3? <lactose>untrusem: I don't believe so. I am just using the default configuration that the installer generated <ekaitz>lactose: there is something in default-services i think <lactose>ekaitz: Looks like either slock or xlock via screen-locker-service-type. How would I go about removing it from %desktop-services? <bjoli>So, I am having some problems with flatpak apps taking a long time to open. Is it a general thing or is it specific to me (running plasma). I just did a test comparing icecat to the firefox on flathub and the difference is several seconds. <lilyp>iirc that's a general flatpak thing related to portals, sandboxing, etc. – unless the experience is significantly worse on guix w.r.t. other distros on similar hardware <bjoli>oh, it is a lot worse than on my other machines. Even stuff in VMs start the flatpak for firefox faster than my guix install does. <bjoli>I found the difference to be very small on tumbleweed. I couldn't perceive a difference at all. <lilyp>hmm, you might want to look into strace then – particularly for stat() storms <graywolf>Anyone bored enough to take a look at #74801 ? <graywolf>Yeah :/ You need to open it directly on debbugs. I am not sure why issues.guix thinks it does not exist. <graywolf>Is Maxim Cournoyer here? I really need to start writing down matching of nicks to people <graywolf>On separate note, how does one comment on a commits on codeberg? On savannah we have guix-commits, where I can respond to an email, how is that done on codeberg? <ieure>graywolf, You leave comments on the commits before they merge (when they're in pull requests). I don't think there's a way to directly comment on commits post-merge. <ieure>You can open an issue to discuss. <graywolf>I see. So for post-merge comments, the way would be to open an issue. <RavenJoad>Why would I need to add -B/gnu/store/...-gcc-toolchain/lib to a wrapper script that invokes g++ from the toolchain?. I figured gcc-toolchain could figure out where all of itself was all the time. Isn't that the point of having a full toolchain package? <yelninei>hello, what would I need to adjust to make a minimal server (just base-services, sshd and dhcpd) not depend on rust. I want to avoid building 30 rust versions for now. It is not really obvious where the dependency is coming from <graywolf>I *think* there was some rust dependency for building the guix logo for the bootloader background <graywolf>`guix graph' could maybe help to pinpoint the cause <hanker>does docker have an hard dependency on elogind? <ieure>hanker, I don't think so? It would be super weird if it did. <yelninei>graywolf: thanks for the tip, looked where %artwork-repository is used and the grub theme seems to use guile-rsvg/ librsvg <hanker>the dockerd shepherd service has an hard dependency on elogind <hanker>i have no idea why because dockerd can launch on seatd-like systems <yelninei>yay, that seems to be the reason. Making a machine depend on rust just to convert a svg to png for a branded bootloader is a bit ridiculous <ieure>hanker, Git blame shows elogind was added to fix #34333. <attila_lendvai>what is the best strategy if i want to run esphome that downloads binaries into ~/.platformio and whatnot? shall i set up a `guix shell --container --manifest x.scm` with mapping a fake home directory somehow? <Rutherther>hanker: the requirement is on shepherd service elogind which is provided by both elogind service type and seatd service type. You can use seatd. <ieure>attila_lendvai, Probably `guix shell --container --fhs' -- but running random binaries off the Internet is not a well-supported usecase in Guix. <attila_lendvai>i'm struggling to map a directory as the home of the user inside a `guix shell --container --user=hacker` setup... i'm getting "chdir: No such file or directory" from this: <hanker>Rutherther, it does work, thanks! <attila_lendvai>guix shell --container --emulate-fhs --user=hacker --network --share=/home/alendvai/workspace/homeaut/esphome-venv=/home/hacker/ python bash coreutils glibc file grep gcc-toolchain -- <hanker>attila_lendvai, add `--no-cwd` to your command-line <hanker>guix shell tries to go to the same directory you are in "currently", so if you make a container in `~/workspace/homeaut/esphome-venv`, it will only share this directory by default and chdir you to it <hanker>but this specific directory doesn't exist in your `/home/hacker` container <hanker>so `--no-cwd` prevents the default behavior of sharing your cwd and chdir'ing you to it <hanker>in most cases when you change user you should use `--no-cwd` <graywolf>Wait, you can use --share=WHAT=WHERE syntax? :O <graywolf>Maan, how I keep missing these things. Looks useful. <yelninei>Another thing that depends on rust: guix-icons: via guile-rsvg and imagemagick <apteryx>odd, my system appears to hang when emulated via kvm/libvirt <RavenJoad>Jeez. Of course I answer my own question now. I was setting LD_LIBRARY_PATH, but needed to set LIBRARY_PATH for gcc & co. to pick up the fact that libc existed... (https://stackoverflow.com/a/4250666) No more -B in souffle's compiler! <Rutherther>RavenJoad: library path should be set when you are in a shell with gcc toolchain <TaelTydes>any advice for getting guix home on alpine to not overwrite my .profile? i'm using oksh as my user shell, & have added the recomended exports to my /etc/profile & to my .kshrc. <Rutherther>RavenJoad: library path should be set when you are in a shell with gcc toolchain <RavenJoad>Rutherther: It is, but this is for a _package_ that calls out to gcc through a non-obvious chain. It goes souffle -> souffle-compile.py -> g++, where the call to g++ is constructed out of an embedded JSON configuration string. I don't want to propagated-inputs gcc-toolchain. <Rutherther>TaelTydes: remove the home profile service type from essential services argument of home-environment <Rutherther>TaelTydes: remove the home profile service type from essential services argument of home-environment <TaelTydes>Autherther: I only have one service in the list, (channel-service), no & essential-services unless that's implicit? Guix 13.2 states that .profile will always be overwritten. <Rutherther>TaelTydes: the default value of essential services contains home shell profile service. You need to remove it if you dont want guix home to manage your.profile <Rutherther>So yes that means changing it from the implicit default value to explicit value that contains all other services there by default, but removing this one <yelninei>I set the grub theme image to #f and removed the guix-icons from %base-pacakges nd i think i got rid of all the rust dependencies <lechner>sneek / later tell graywolf / i think Cournoyer is apteryx here <attila_lendvai>FTR, i've managed to compile for and flash an esp32 board using this: guix shell --container --emulate-fhs --user=hacker --no-cwd --network --expose=/dev/ttyACM0 --share=/home/alendvai/workspace/homeaut/esphome-venv=/home/hacker/ python python-pip nss-certs bash coreutils glibc file grep gcc-toolchain less which git -- bash --init-file <(echo "source bin/activate; export TERM=$TERM; unset C_INCLUDE_PATH; unset CPLUS_INCLUDE_PATH; export <apteryx>civodul: hi! I'm off to bed, but in case you hadn't seen, it looks like I found something "interesting" in Shepherd; see bug#77115 <lechner>apteryx / yeah, that's not exactly what i meant. i don't file bugs anymore <RavenJoad>Is there a way to run a "system test" for an individual package? I'm packaging souffle and I want to make sure all of its features are working properly (interpret, compile, use SQLite, use Swig, etc.). They all work on my command line manually, but some automation would be nice. <lechner>RavenJoad / Do you want to run an individual system test? <RavenJoad>I want to create a system test, but just for a package. I want to test usage of souffle (the tool), since its unit tests check for correctness, not usage. <lechner>RavenJoad / yes, that's possible. i modified the mdadm test in a patch on Mumi but even the version in master might be helpful to you <lechner>RavenJoad / You will effectively test all packages needed for your test and add an error condition for yours <RavenJoad>Is there a way to tie that to a package as well? That way building souffle will also run the system test and will fail if the system test failed for some reason? I don't want souffle users to find out SQLite support is broken by running their stuff. <lechner>RavenJoad / not that I know of, but I am working on a test infrastructure that will test your package when installed. not ready yet, though <lechner>How about enabling or disabling features at build time? <RavenJoad>That would be great. Souffle has a ton of unit tests (4500+), but they check that their tool is correct. They don't check that a logic program -> c++ -> binary compiles or that that binary can use sqlite to access info. <RavenJoad>Right now, almost everything is enabled at build-time. I could always disable things, but SQLite & swig support (the only 2 extensions it has) are kind of important. <RavenJoad>I also need to wrap souffle's compiler script, so I wouldn't want Guix to ship a tool that is broken (unable to compile a logic program to a binary). <lechner>okay, you may have a classic use case for my testing infrastructure, which is rare <lechner>and how (and when) do you know, as a packager, when they are broken? <RavenJoad>When does support break? Almost never(?), I guess. There are only a handful of commits over the past year. <RavenJoad>As a packager, you would know souffle's compile script broke when g++ could not find crt1.o for instance. (I fought that for a while last night). These tests would be to make sure the functionality I expect as the packager continues working over time. <lechner>RavenJoad / okay, so the issue is that you cannot detect the broken prerequisite during build time? <Rutherther>lechner: is there any more information available about the 'test infrastructure that will test package when installed' that you're working on? <RavenJoad>More or less. The compile script embeds information in it that is not tested unless you use the script to compile something (it embedded the build directory by default for instance). <lilyp>you could use the old autoconf trick of checking whether it compiles a file <lechner>RavenJoad / well, it's kind of vaporware in Guix right now, but you can look at Autopkgtest in Debian (and I will post a few links shortly). i have experience in administering similar services in Debian and plan to use cbaines's build coordinator to do it <RavenJoad>lilyp: The script is templated in the main repo and filled in by cmake during configure. Plus it relies on souffle compiling its libraries for the compilation passes. <RavenJoad>I ask because I recently learned nixpkgs has facilities where usage tests can be defined to test a package's usage after it is built. <lilyp>the current pattern is to move the check phase after install <RavenJoad>I still want the normal check phase, since that checks whether that the compiled libraries actually do the right thing for test programs. <RavenJoad>These usage tests would have to happen after install, since I also need to patch out store & build paths from souffle's compiler script. <lechner>for a piece of software I maintained I enabled building for each commit on salsa. the build took 45 minutes, the tests six hours during which the build result (or status) were not available. it's much better test separately <Rutherther>RavenJoad: re nixpkgs: those are full system tests (vm), but yes, it's possible to say from the package arguments (in nixpkgs packages can pass through arbitrary arguments) that there is a test associated with it, that can then be picked up by CI. So they are always testing the full system configuration, not just the package <lechner>Rutherther / are those tests in nixpkgs part of the derivation? <RavenJoad>Rutherther: Yes, they are testing a full system test, but that full-system test is attached to the package's definition file, so you can see a package's usage tests in its definition too. <[>pactl send-message /card/bluez_card.<mac address>/bluez list-codecs only shows [{"name":"sbc","description":"SBC"},{"name":"sbc_xq_453","description":"SBC XQ 453kbps"},{"name":"sbc_xq_512","description":"SBC XQ 512kbps"},{"name":"sbc_xq_552","description":"SBC XQ 552kbps"}] <PotentialUser-98>Hello everyone, is it possible to use guix home without overwriting .profile file in my home directory? <RavenJoad>lechner: Yeah, most of these unit tests are quite quick, but some take a minute or two. I have a high-core-count machine to parallelize those tests on, on Cuirass it might be much longer, so I don't want to make the package take forever to show up. But these usage tests will effectively be create tiny files (textual and SQLite), create a test logic program, run the interpreter, run the compiler, and generate swig interfaces and that's <Rutherther>lechner: no, they are not part of the derivation, they are only passed through as 'tests' attribute, so in nix you can then do "pkgs.some-package.tests", that will return you the list of tests for that package (if it exists). It's just sort of a way for adding arbitrary metadata to packages. Something like having home-page/description in guix packages (though nixpkgs has that in a separate attribute called meta, so it's not really 1:1 analogy) <Rutherther>then their CI will run those tests after building the package <RavenJoad>So I want the usage tests to be a way to make sure the substitute*-s on the compiler script continue working. <Rutherther>then their CI will run those tests after building the package <Rutherther>PotentialUser-98: yes it is, you need to prevent it from managing that .profile file, which means changing the essential-services of home-environment, specifically removing the home-shell-profile-service-type from them <Rutherther>PotentialUser-98: yes it is, you need to prevent it from managing that .profile file, which means changing the essential-services of home-environment, specifically removing the home-shell-profile-service-type from them <attila_lendvai>ping (icmp) errors in a guix shell --container ("unknown protocol icmp."). what can i do? it's probably some permission, or i need to expose comething, but i can't find anything online <Rutherther>attila_lendvai: could you clarify on how you were running ping in container? ping from inetutils needs a capability to run <attila_lendvai>Rutherther, just added net-tools and inetutils to the guix shell, and invoked ping from inside <Rutherther>attila_lendvai: to fix the exact error you have at hand you need to share your /etc/protocols file. But as I am saying, ping needs capabilities, it's not possible to be ran from the store <attila_lendvai>i gave up on this, but for curiosity: with --share=/etc/protocols now it prints "ping: Lacking privilege for icmp socket." <ieure>attila_lendvai, That's exactly what Rutherther has been telling you. <attila_lendvai>ieure, i know. i'm just saying that sharing that file into the container moves the issue one step forward <tschilp>Hi! Does anyone have an idea why this job from my home-configuration: http://paste.debian.net/1364046 gets run multiple times? The log shows http://paste.debian.net/1364048, I'm kind of irritated as I've renamed the script, reconfigured and the old script is still being tried, while the new one gets fired twice (as was earlier the old one). Do I have to delete some cache file? If I look at the destination repo, it's really created <Rutherther>tschilp: maybe you have currently two mcron instances running? <ieure>tschilp, I'd look at the crontab that's generated to make sure the sexps produce the crontab format you expect. <tschilp>Rutherther: that's what I assumed, but I actually logged in and out (I think so at least), and yesterday I deleted about 1000 doubled snapshots which where created from the old config... mhm <Rutherther>tschilp: I would rather look to processes than rely on logging out and in <tschilp>ieure: good idea, mcron is quite mystical to me still ;) <Rutherther>tschilp: no, I mean literally looking into processes - ie. "ps aux" or "pgrep mcron" <Rutherther>I don't know why your ps aux doesn't show it. Anyway can you check what those processes are by the process id? because if it was three mcron processes, something must be wrong there. But it can be just processes with mcron in name just partially <Rutherther>s/with mcron in name just partially/just part of the name could be mcron <tschilp>but yes, all in all its three of the same processes... <tschilp>and I assumed to have just the last one reported by ~herd status mcron~ 23657. I'll reboot now! <Rutherther>okay. Then I am pretty sure this is the cause, multiple mcron instances running at once <Rutherther>I don't know why your ps aux doesn't show it. Anyway can you check what those processes are by the process id? because if it was three mcron processes, something must be wrong there. But it can be just processes with mcron in name just partially <Rutherther>s/with mcron in name just partially/just part of the name could be mcron <Rutherther>okay. Then I am pretty sure this is the cause, multiple mcron instances running at once <Rutherther>tschilp: the thing is that when home reconfigure doesn't reload shepherd properly, the last shepherd instance will get replaced with a new one. But the older services will still be running. When this happens your herd status know only about the last one. Shepherd instance knows only about services _it_ started. I think this happened to me as well at some point after guix home reconfigures, but I was never looking into it <lechner>Rutherther / you have done some great debugging today! first attila_lendvai and then tschilp <lechner>Rutherther / what would be a good way to specify tests (on the Guix level) for us? would we bracket the package records with something bigger, potentially also specifying recommended packages, or can we do the attribute thing, as well? <tschilp>Rutherther: right, after a reboot I just have one mcron running... how would I manually force-reload shepherd after a home reconfigure? I'm always getting a message about certain jobs not being reloaded, because they are already running... and very rarely manually restarted a service so far. But had tons of double backup jobs... Well better too many of them :) <lechner>tschilp / not sure if you have this option on the Home level, but the Shepherd's timer feature is awesome (and had #:wait-for-termination #t) <tschilp>so just look up the actual PID by ~herd status service~ and then kill -p $OLD_PID :) <tschilp>I got lost with home-shepherd-timer-service recently, and switched back to mcron. I'll soon give the timer a try again :) <lechner>yeah, they cost me six month as an early adopter by i love every part of them <Rutherther>lechner: I am currently undecided on what a good way to specify tests would be, I haven't given it much thought. I think both ways you suggest seem reasonable. I think the nixpkgs way is okay, but nothing 'special' - it gives a way to link packages to tests, but it could be done equally well from the test side saying which packages are considered to be tested by the test, or by a separate file that would link packages to tests. So I wouldn't decide... <lechner>Rutherther / would it make sense to rename our current package record to 'build-instructions'? <vagrantc>are #true and #t inherently identical in guix? <lechner>Rutherther / and use package for the embracing record <Rutherther>lechner: could you clarify? because currently I would say packages are really packages, they contain build instructions but not only that, they have a name, version, home-page, description, synopsis, all this metadata I would imagine is a 'package', whereas only the arguments and build-system are what are build-instructions <Rutherther>lechner: could you clarify? because currently I would say packages are really packages, they contain build instructions but not only that, they have a name, version, home-page, description, synopsis, all this metadata I would imagine is a 'package', whereas only the arguments and build-system are what are build-instructions <vagrantc>looks like in this particular case, #t and #true are interchangeable, at least if linux-libre-arm64-honeycomb package definition is correct (it uses a mix of both) ... guix style seems to prefer #t (why, oh why?) <lechner>Rutherther / okay, maybe you are right! things like synopsis and home-page do not figure into the derivation? <RavenJoad>vagrantc: Those are guile values. You can go to the guile repl and see for yourself. (and #true 3) => 3, (and #t 3) => 3 (and #false 3) => #false (and so on). <lechner>vagrantc may have been asking a "syntactic" question <RavenJoad>lechner: For the kind of tests I'm thinking of (usage tests), I feel they should be attached to the package. But more integration style tests (like the system ones) should be put elsewhere. <lechner>RavenJoad / also want to attach them to the package, but I do not believe the package should be rebuilt when the test definitions change (unless they are shipped as part of upstream) <lechner>potentially the same with the idea for recommended packages that's been floating around. <Rutherther>lechner: the name and version do, because they are in the output folder name. The home-page, synopsis, etc. don't <RavenJoad>I'm of the opposite. If a package's usage tests change, the package should be rebuilt (re-derived?) enough to reflect that. Does home-page cause a re-derivation (not rebuild)? <RavenJoad>Redo the derivation building, building the .drv file (which has references to inputs, outputs, etc.). Perhaps that is a term I just made up. <Rutherther>if the derivation changes, hash of the output changes => rebuild is forced <Rutherther>so there is no such thing as re-derivation, but not rebuild <RavenJoad>Perhaps usage tests are LIKE dependent packages. If the usage test changes, the package under test should not be recompiled, just test. <RavenJoad>I know there is no such thing (functional style and all), but I meant it to be a way to express _something_ must change, but a rebuild of the actual package may not be necessary. <lilyp>RavenJoad: or like profile hooks – when one package in a bunch changes, rerun the tests <lilyp>I do think we need a notation for those special hooks tho <RavenJoad>Pretty much, yes. Usage tests like these should ideally only have the package-under-test and some sort of scripting tools available and nothing else (no need to spin up a VM unless cross-compile for instance). Reuse the containerization/sandboxing used for builds. <Rutherther>RavenJoad: I don't know how it's planned to make the tests exactly, but if they are going to be a derivation as well (ie. what nixpkgs does where a package is built with a script to build a vm and the scripts to test mounted to its fs), the change would be easy to spot in that case, since the test derivation changes when the test changes <lechner>the most important part of a new testing system for Guix is that the test prerequisites are separated from the build prerequisites. it will have a very beneficial effect on the package graph, of which there are then two: one for building and one for testing <lechner>building binaries needed for tests should only happen in the testing stage <Rutherther>lechner: I might have missed the answer when I asked the first time, but is there more info available about this new testing system? Or is it just an early idea? <RavenJoad>Rutherther: Exactly. That's the behavior I would expect out of this system. <RavenJoad>lechner: Agreed. Keeping the actual package graph small despite a large testing graph is good too. <lechner>i used it for many years and intend to copy it. guix will be able to sidestep many of the container issues <lechner>a substitute should only be shipped if it builds and passes tests <RavenJoad>Exactly my intention with the usage tests for souffle. I don't want to ship a broken compiler because I missed a program to wrap. <RavenJoad>That Debian thing is pretty much what I was thinking of. Although not printing to stderr might be a bit too restrictive (but I have not read too deep yet). <RavenJoad>That's more of an implementation detail for now though. <lechner>maybe you, Rutherther and I can work on it together <luca>isn't that just wireguard? <RavenJoad>lechner: We'll see. My schedule is kind of booked until April right now. Conference papers and whatnot. <RavenJoad>Is there a known resolution to this error from fontconfig? "Error: fontconfig: Didn't find expected font family. Perhaps URW Type 1 fonts need installing?" <Rutherther>lechner: I would be happy to participate in this. On the other hand I am not sure how I will be able to manage time-wise, while I might be active in this channel for quick debugging procrastinating other stuff, this will probably require quite a significant time commitment which I might not be able to get in the few following months <lechner>RavenJoad / Rutherther / all the same for me. my idea was to start small, maybe split some work, and keep each other motivated. from my experience building a similar system, it's easy to make structural mistakes in the beginning. that's why I thought three heads might be better than one <RavenJoad>lechner: Agreed, that's the way to do it. I'm just busy until late-April/May. This could be something I work on during the summer, alongside a bootstrapping Ada compiler/interpreter. <untrusem`>I have just packaged one package that I have not submitted, It was just changing the commit hash and sha256 hash <untrusem>ohh mullvap has been packaged by someone in their channel <bjoli>lilyp: what are stat storms? <lilyp>a bunch of stat() syscalls when you start an application <noe>untrusem: if you are talking about the one in the small-guix channel, beware that it is not built from source <untrusem`>noe: So the packages just builts from the deb package provided by mullvad <noe>that’s what it seems like reading the package’s source <untrusem`>for that they would also need mullvad service <untrusem`>so I added the channel, I can just use the service in the config file <untrusem`>I would like it to be it only for the home environment though <noe>untrusem` I think it needs to be in your system config since it creates user accounts for the daemon <RavenJoad>Does Guix normally like to install HTML documentation generated by doxygen? This package's HTML docs are just 300MB. man is 13M. <civodul>RavenJoad: no, we generally don’t do that <civodul>or if we do, as a separate output (i think ‘glib’ has something close to that, for instance) <RavenJoad>That's what I thought. Would a separate output be worth it instead? mpd does this. <RavenJoad>I don't really care either way, but since this is C++ documentation, you lose a lot when you dump this doxygen to manpages. <civodul>well, doxygen/javadoc-style documentation is often not so great anyway :-) <civodul>i know of counterexamples, but i think they are exceptions <RavenJoad>Also true. If I do support it though, should I dump it in a different output? <khada>Hello guix community, is there a way to delete or exclude some of the gnome packages? <Rutherther>khada: it should be, the gnome-desktop-configuration has three fields: core-services, shell, utilities that you can tweak to remove some of the packages <Rutherther>khada: it should be, the gnome-desktop-configuration has three fields: core-services, shell, utilities that you can tweak to remove some of the packages <khada>Thanks, Rutherther I'm trying to understand how it works. May I ask for an example? <RavenJoad>khada: It's pretty straightforward. The gnome-desktop-service-type accepts a single thing, a gnome-desktop-configuration. The configuration "struct"/record has a bunch of fields. The core-services field accepts a list-of-packages, which is (as the name suggests) a list of Guix packages. <RavenJoad>So (services ... (gnome-desktop-service-type (gnome-desktop-configuration (core-services (list pkg-foo pkg-bar))))) is a poorly-formatted example of how to do what you want. <arebi>Hello Guix Users, Quick Question: Anyone using haunt static site generator here? I am trying to extend the post module to include additional attributes for the generated <html> tag, for example: the current markdown (haunt reader commonmark-reader) helps to generate the html of the post by <div><h1> My first blog </h1>........</div> , I am trying to add additional attributes to the div tag (such as id, class, style, title) as key value p <arebi>rs in the myfirstpost.md file (in addition to the existing key . value pairs). can you please advise with an approach? <civodul>arebi: hi! in some cases i post-process what commonmark-reader does to do things like you describe <khada>I can reconfigure now. Thanks RavenJoad :-) <mange>arebi: I was thinking that you could do it in your post-template. Match on post->sxml and rewrite it to add the bits that you want.