<surpador>Are there any known problems with perl-gtk3? The very basic example code on CPAN <https://metacpan.org/pod/Gtk3> throws a bunch of critical errors, and I'm not sure if I'm doing something wrong or there's a problem with the package in Guix
<elb>so what's the best way to test a patch to the guix package tree on my own system?
<elb>assuming I've checked out the guix tree and inserted a package
<mirai>I've managed to tame the docbook-xml packages
<mirai>no longer it is needed to cargo-cult substitute* magics or other kinds of regex trickery
<surpador>If I'm patching a package to look for a data file in the store instead of a system directory (e.g., in #$output/share instead of /usr/local/share), should I also patch the provided man pages to note that change?
<mirai>surpador: the build system may already handle this
<mirai>if the manpages are processed through M4 for example, it shouldn't be too hard to change it to depend on DESTDIR from the build system
<surpador>Oh gotcha. I'll take a look at it and see what I can do. Thanks for the help!
<Guest53>webantipode: rekado: Oh! I've been blabbering about my approach to Erase Your Darlings, in which most state is relegated to `/persist` because the root is constantly rolled-back or even tmpfs'ed;
<Guest53>In applying the same approach to `/home`, the GC roots are going to be in a separate (BTRFS) volume anyways, so I might actually be able to implement this
<Guest53>(doesn't add as much as a single-user w/ FDE, but since when has utilitarianism stopped me?)
<efraim>I keep hearing about zig switching to self hosting but right now it looks like even in 0.10.1 it can still be bootstrapped from the C source and then it recompiles itself
<civodul>i saw a post about them ditching the C++ code base
<civodul>maybe it's for the next release or something?
<efraim>From the best I can find they have an alternate stage1 at github/zig/zig-bootstrap which (now, after the 0.10 branch) uses a wasm binary built with zig to bootstrap stage2, which would then build the stage3 final zig. right now stage1 is build using C++
<efraim>it looks like the 0.10.1 release builds and passes tests AND greatly decreases the memory needed to build it. If so we can use 0.10.1 to bootstrap future zig releases if necessary
<efraim>took about 3x as long to run the zig tests as to build zig on my machine, 18 minutes to build, 50 to run the tests
<ssb>Kolev, I tried that and failed (someone please correct me if I'm wrong) -- there is no user-friendly way to do that. Yes, there is 'guix system container' but the resulting container is read-only, you cannot using "guix build" or whatever inside it. I found no other way to install full-fledged system in the container, and no way to use ('chroot' into) existing guix system from a foreign system. I think that
<rekado>ssb: you can use “guix build” inside the container if you expose /gnu/store to the container (rather than just the default subset), bind the daemon socket in the container (or share network to talk to the daemon on the outside), and have a “guix” executable to serve as a client.
<rekado>since this will talk to the daemon outside of the container it will modify /gnu/store, which is fully exposed, so the results are visible in the container.
<ssb>rekado, that assumes you already have working guix daemon outside the container. Which is not my case, unfortunately.
<ssb>that is the whole idea -- to have working guix system inside a container (forget chroot, okay) from another, foreign system.
<mroh>did someone wrote an udev rule that refreshes the avahi substitutes discovery cache on laptop lid open?
<civodul>mroh: hi! i don't think udev has anything to do in there, but i agree the cache isn't getting refreshed
<paul_j>There is a small typo in the blog post he put up - there is a line about half way through: (write-derivation drv (current-output-port)), which I think should be (write-derivation manual-drv (current-output-port))
<gabber>i need to acquire an IP address via DHCP (with WPA athentication) but i also need to configure entries in resolv.conf. what is the way to go? (static-networking) won't allow leave the addresses-field blank and i'm not sure how to otherwise set resolv.conf
<apteryx>anyone else using gglobal in emacs? 'find reference' never seems to produce anything, although git grep finds some
<bjc>you probably want the ‘extra-special-file’ service, and you'd put that in the top-level ‘services’ field, not in ‘modify-services’
<bjc>that said, if you're using dhcp, that file may get clobbered by your dhcp client anyway. i'm not sure
<gabber>bjc: thanks for the hint! i'm not sure about your assumption; i have a somewhat unusual (?) network config where i have to define nameservers and domains in my resolv.conf but still retrieve my actual IP via DHCP -- at least that's the way it works on my Debian machine
<bjc>yeah, it'll depend on how your dhcp client is set up. i think the default is to have it write out resolv.conf based on the nameservers your dhcp server sends, but ymmv
<tschilptschilp23>Hi guix! Do you have a hint using emacs-orgmode tramp remote command execution from guix on foreign hosts? My problem is, that I receive a '/bin/sh: 1: /gnu/store/d99ykvj3axzzidygsmdmzxah4lvxd6hw-bash-5.1.8/bin/bash: not found' when issuing a small script on a host after authentication. Is there a way to tell tramp to use the remote shell? At work in our debian/ubuntu world this conflict does not appear, as it's all '/usr/bin/bash'.
<apteryx>jokes in the source: (define-public global ; a global variable
<tschilptschilp23>OK, got it. I must specify 'bash' and not take the semi-wildcard 'shell' ;)
<greenfork>Hi, I'm trying to find information on what is stateful and what is stateless in Guix System. I don't seem to be able to find it in the docs, could you please share a link to some resources on this?
<gabber>greenfork: what do you mean exactly? are you referring to the "package manager" or the system? IIUC you can configure your operating system, your custom software package as well as your very personal home configuration in a stateful manner
<greenfork>gabber: I have read bits about "not changing anything in /etc because it will be overwritten with the next reconfigure", I'm trying to understand what would be an "ecological" way of keeping state on my system but as little as possible
<greenfork>What to do and what no to do. I'm deploying Guix System on VPS so it is referring both package manager and the system
<gabber>there's a small paragraph in the manual (section 1.2 GNU Distribution): "With Guix System, you _declare_ all aspects of the operating system"). usually you want to put *everything* into your system-config file, because then your system only relies on changes in there. what state do you want to keep? what do you mean by ecological?
<PotentialUser-19>Hey two quick questions: Does Guix work on aarch64, and what's the experience like compared to NixOS?
<gabber>PotentialUser-19: yes and i don't know NixOS. But if you ask for opinions here people will most probably tell you how much better Guix is in every aspect possible ;)
<greenfork>Right now I will need a file for a SQLite database, some directory for videos. And I assumee I might compile a program that is not declared through the config.scm file. Are there any "dangerous" directories that I cannot touch so that my things don't get overwritten?
<PotentialUser-19>Lmfao that's fair and to be expected. I guess I should ask about what sucks then, like what are the pain points you experience gabber?
<greenfork>"Ecological" means being in harmony with the rest of the system, following conventions, not interfering with the intended way of the system configuration
<mirai>PotentialUser-19: the perceived vantage from NixOS is that they've been longer
<gabber>greenfork: i see. i would try to configure all aspects of the system (that is, stuff that should /just work/, without any specific data) through a system config file. i'd configure everything that goes into /etc through the config-file. if you need (empty) files and directories you could manage them like-wise -- but i guess Guix is adaptive enough to be used in a manner that suits you best
<gnucode>gabber: it said it did. And I rebooted, but after running guix system list-generations ... guix deploy is not creating a new generation. So for some reason the old configuration is still in use...
<gnucode>I was using the -x -- sudo herd restart nginx command.
<gnucode>gabber ok now it is working. It seemed like "guix deploy config.scm -x -- sudo herd restart nginx" did not actually deploy the latest config.scm. But "guix deploy config.scm" did. Weird.
<gnucode>gabber it took me 2-4 hours to reset up my server with guix system. I am estimating, because I don't know the actual time. Suppose your server crashes, you lost all your backups and all that you have is your config.scm. How long would it take you to reset up your server do you suppose?
<gabber>gnucode: i don't have such a server running ATM, but if i had all the system specifics in my config.scm i'd be way faster than with most other distros :)
<mirai>I see that %default-nftables-ruleset comes with this description: This service comes with a default ruleset %default-nftables-ruleset that rejecting all incoming connections except those to the ssh port 22
<gnucode>mirai I set up my ssh to run on a non standard port. It's not accepting connection on port 22. :)
<gnucode>ssh -p 24953 firstname.lastname@example.org That's how I connect. Except I use a different port. :) And no I'm not really familiar with nftables. Trynig to get better at it.
<gnucode>mirai I want to use endlessh on port 22. :)
<Apo11o[m]><gnucode> "Apo11o: what's the issue with..." <- Just found this https://issues.guix.gnu.org/57083 I’m not familiar with ruby but setting up themes etc. with gem and bundled produces errors. Will check again if someone has posted any solutions
<gabber>huh. i have never used ggtags -- but the -e implies Emacs style ctags (i don't know whether and/or how these are related)
<gabber>how can i distribute a set of IP addresses to client with dnsmasq? i'm missing fields like "dhcp-range" or "dhcp-option" in dnsmasq-configuration in Guix.
<old>I want to update lttng-modules (kernel module) from 2.13.6 to 2.13.8. However, the build is not reproductible anymore. How does one usually fix that?
<old>I would for starting to see which files are not the same between two rounds
<gabber>old: there's utilities to inspect differences in binaries e.g. diffoscope. i'd suggest that if there isn't something more obvious that you could deduct from the sources itself (like including the build date/time or some random number being included)
<old>gabber: But how can I get the final two directories for comparaing the outputs?
<lechner>apteryx / why are the inputs declared in guile-irc at all, then?
<apteryx>if your guile irc bot is a script rather than a library for example, it's best to define the guile as regular inputs (not propagated), and wrap the script with GUILE_LOAD_PATH and GUILE_LOAD_COMPILED_PATH.
<lechner>i switched to the guile build system. do i have to do anything for the PATH stuff?
<apteryx>I think so; since installing binaries under bin/ is not handled by the build system directly, even less wrapping these
<lechner>apteryx / i just declared 'gnutls' as an input. do i still have to do anything else? if so, do you have an example?
<apteryx>what does it use from gnutls? scheme modules?
<jpoiret>i'm not saying there aren't any instances in the Guix codebase :)
<futurile>jpoiret: that works - and now I feel a bit "duh" - thank-you
<jpoiret>but it's better to say either #$(this-package-input ...) or #$(this-package-native-input ...) depending on if you need it for compilation or to run
<jpoiret>i mean, if you need it natively or for the target... :p
<lechner>jpoiret / thanks for the pointer. i changed it
<jpoiret>let's say it's better hygiene, that way more "novice" Guix hackers will not try to use (which ...) instead of #$(this-package-input ...) when e.g. patching exe paths, which would result in cross-compilation problems!
<jpoiret>lechner: no need to self-deprecate, the distinction between all of these methods is 1) tenuous 2) not documented enough 3) nowhere does it say what style should be used preferrably
<davidl>so I wanna submit a package called wayvnc, which I have added to gnu/packages/vnc.scm. It had 2 dependencies which I also added there, which don't seem to be used for much except as dependencies to this package and possibly others by the same author. Do I have to split this to 3 commits, or can I just submit a package like "gnu: add wayvnc with dependencies..."?
<lechner>but there is no temporary profile in GUILE_LOAD_PATH or GUILE_LOAD_COMPILED_PATH. I am using the Guile build system with 'guile-3.0' as an input
<dokma>lechner: yeah, that just marks packages as being installed manually, meaning don't uninstall this package even though nothing depends on it.
<jpoiret>lembrun[m]: there's probably a bug with qemu virtual machines right now with 6.1
<dokma>lechner: what I need to say is: "I'm installing this package because my script /path/blah.scm depends on it. If the script is present, the package is needed, otherwise, if nothing else depends on it, the package can be removed." This is quite different from marking a package as installed manually.
<lechner>dokma / maybe you need to package your script