<lfam>mdevos: You'll be more likely to get an answer after the new year's weekend
<nij>leoprikler: This is related to a several hours ago. - Hmm what I was hoping for is to recover my system on any machine without any possibilities of dependencies failing. Without managing emacs packages declaratively.. I wouldn't say it's fulfilled :S
<Formbi>you can use a guix manifest and use-package in init.el
<nij>use-package doesn't seem to be declarative.. yes?
<nij>It pulls packages from an external repo that could have broken dependencies..
<nij>ryanprior: Right, I'm aware of lockfiles, and it seems that most of the time it does do the job.
<nij>And it does seem to be the best that we have now..
<ryanprior>Okay cool. If it doesn't do the job sometimes I'm sure they would appreciate bug reports!
<ryanprior>I'm really good at writing bug reports and would be happy to help if that's something that intimidates you (or anybody else reading)
<nij>ryanprior: I might be a little bit too theoretical before actually trying. Perhaps in emacs it's fine, as there are not too many packages that have the same name, same version, but different behavior. Things are different outside of emacs.. so maybe that's why nix and guix have to take care of that more carefully.
<nij>I will report if I found something that's actually a problem! :D
<ccao001[m]>Hi guix! If I'd like to say build icecast without curl support should I inherit from the existing package definition and then add the appropriate configure flag to ```#:configure-flags```?
<ccao001[m]>If I want to quickly just hack the icecast package on my own system and build my custom build of it
<ccao001[m]>guix edit doesn't allow me to save my changes as it is read-only
<lfam>For something like this, which sounds like a custom package for a special use case, I recommend making a custom repo and using it with either the GUIX_PACKAGE_PATH environment variable or a "Guix channel"
<ryanprior>bashrc is for both interactive and non-interactive shells
<lfam>`guix environment` operates by launching a new shell with different environment variables. The file ~/.bashrc affects the environment of new shells. If your ~/.bashrc exports environment variables — especially ones related to guix — then `guix environment` may not work correctly
<lfam>ryanprior is right, but the main distinction here is between login and non-login shells
<ryanprior>if you run a bash script it'll source your bashrc
<ryanprior>which I think is kinda bonkers but that's what it is
<lfam>Basically, environment variables that should always be in effect should be exported while logging in, and they will propagate throughout the environment
<ccao001[m]><ryanprior "if you run a bash script it'll s"> is this the same for all shells or just gnubash?
<ryanprior>(what do y'all think about creating a pure functional shell scripting environment with nice I/O monads that's extensible in Guile)
<lfam>For the other shell (zsh), there is ~/.zshrc and ~/.zprofile, and the same points stand
<zamfofex>Hello, Guix! Has anyone ever asked for a Deno package? I tried installing it with Cargo, and the only really problem I ran into was needing to install curl for “rusty v8” to build correctly. (So I think that means a package would be easy to set up.)
<jlicht>zamfofex: It depends: it seems that rusty v8 includes building the entire v8 engine from source (yay), but for guix to be able to do that, you need to state where those sources come from.
<jlicht>so you might need to package those sources separately as well, and get rusty v8's build process to pick up on the fact that you already have copy of the sources for them to build.
<PurpleSym>Where and how would I add test cases for the python-build-system?
<civodul>rekado_: hi! the command from "sudo herd schedule mcron | grep index" seems to find Xapian
<civodul>PurpleSym: so far there aren't test cases for build systems per se
<civodul>perhaps what you could do is isolate the relevant functionality so you can write unit tests for it
<civodul>just like we do (guix build gremlin) for instance
<moesasji>system to use it in a way that the system uses the patched xkeyboard-config. Can someone give me a pointer? An example how one would exactly use a personal channel to replace a package like xkeyboard-config would be ideal...
<daemonspudguy>No. But I said by default. You have to remember that Debian's nonfree and contrib repos aren't enabled at installation. You have to make a conscious decision to use them
<leoprikler>Still, I'd claim that the comparison is somewhat off, given that Debian is not FSF-approved. That said, there is some potential for bugs unique to Guix, as others have e.g. reported issues, that didn't exist in Trisquel.
<abcdw>Do someone knows, why goto definition doesn't work in geiser? (for some cases it work, but some does not) For example I'm at line 610 at gnu/services.scm on (activate-current-system) form, press M-. and get "Geiser: cannot edit symbol at point ..."
<civodul>abcdw: that's because the module that provides activate-current-system is not in scope
<civodul>in this case, that's because activate-current-system is actually called in a different stage
<candan>Hello everyone! I'm attempting to install jupyter notebooks but I'm running into some trouble. I
<candan>I've `guix install jupyter guix-jupyter` but on running `jupyter notebook` I'm getting the error `pkg_resources.DistributionNotFound: The 'six' distribution was not found and is required by traitlets
<leoprikler>fwiw rather than installing everything locally, you might give good ol' guix environment --ad-hoc a try.
<leoprikler>once you've figured out a set of packages, that lets you actually run jupyter, you can install that
<candan>New to guix so just reading up on --ad-hoc now...
<abcdw>civodul: thank you, it seems mostly working!
<civodul>candan: here's one that works for me: guix environment --ad-hoc jupyter python-notebook guix-jupyter -- jupyter notebook --no-browser
<candan>leoprikler: boom got it! ` guix environment jupyter guix-jupyter -- jupyter notebook`. It takes quite a while to download stuff and load up - will it do so every time or can I maguixally load up this same environment next time?
<leoprikler>candan: that actually pulls in all the dependencies of jupyter and guix-jupyter
<candan>civodul: oops thanks! Didn't see your post. Ok so what are the advantages of your method over the one I used?
<candan>Oh. Ah yes I did see that in the intro video but forgot it - thought it referred to a hash
<rekado_>candan: “--roll-back” is just a short-hand for the more generic “--switch-generation”
<avalenn>and the equivalent of "nix show-derivation"?
<candan>rekado_: oh makes sense... switch to the *lsat* generation
<candan>is there any reason I wouldn't want to just use guix as a straight replacement for apt? Even ignoring the unique benefits of guix. Just as a package manager with more up to date packages than, say the debian repositories?
<lfam>candan: Guix on other distros lacks setuid binaries. I find it easier to let Debian handle the system layer and use Guix for applications
<lfam>Also, on Debian, services and packages are intertwined. So by installing a package from guix you may lose some functionality
<lfam>I mean, installing the package won't make you lose anything. But trying to replace the Debian package with a Guix package
<lfam>Like, on Debian you can do `apt install nginx && systemctl start nginx` and it works. There's a lot of setup that would be required after `guix install nginx`, and it would be hard to keep track of
<lfam>It is really nice to use Guix on Debian, though
<candan>I suppose if you did, say, install and run nginx from guix though, one benefit would be, eg config files all being stored in ~/guix-profile/etc/, which would make... i dunno, backups easier, assuming you follow symlinks?
<candan>Not esaier but simpler... you only need to backup your home (symlinks including, again)
<lfam>candan: I don't think that nginx config files would live in ~/.guix-profile/etc when installing nginx with guix
<lfam>They would go wherever you put them, but guix wouldn't handle them
<morgansmith>so I installed nix so that I could install signal-desktop, but the fonts don't work. Does anyone know how to get them working?
<morgansmith>I tried that, but nix says I'm supposed to set the fonts.fonts setting instead. but I have no clue what that means. I found a font config snippet on the nix website and copied that into my config but now it tells me fonts.fonts is an unknown setting. I'm very very lost
<moesasji>morgansmith you could also opt for the flatpak solution for things that are not yet available on guix
<morgansmith>flatpak was giving me grief so I was trying to see if nix would give me less grief. Other than the font issue, they seem to be roughly the same amount of grief
<morgansmith>does nix have multiple config files? I'm putting my stuff in the /etc/nic/nix.conf file which according to nix manual is the only configuration file but everyones configs online look pretty different to this file
<jgart[m]>morgansmith: I would also ask in #nix:matrix.org to see how to set up fonts on a foreign distro
<jgart[m]>There are people using nix on ubuntu, fedora, etc...
<morgansmith>turns out I was using the wrong configuration file. also turns out they have 3 different manuals. I really don't like their documentation
<jgart[m]>Yes, there is a manual for NixOS which is the distro itself, Nix the language, and Nixpkgs which are the source files for the package definitions, services, etc...The Nixpkgs manual shows guidelines for how to contribute to nixpkgs and how to do specific things with the source tree as needed (e.g. installing unfree packages, overlays, overriding, etc...)
<morgansmith>I'm just upset because 2 of the 3 manuals have a preface letting you know of all the manuals. And I had to start with the manual that doesn't have that preface
<jgart[m]><lfam_ "morgansmith: It means the source"> What do you feel is lost?
<jgart[m]>I see it as both ways having pros and cons
<lfam>jgart[m]: The name will be something like "/gnu/store/a79yv1yw5l645d5vp255gqdn52vmb34d-git-checkout"
<lfam>It's better to have the name, this is why the linter warns about it
<morgansmith>lfam_: I literally see no difference in paths when you have that line vs no having that line. maybe I'm not testing it right but removing that line still results in /gnu/store/6zk2cccvzvlskq7yw5vkdmax7mkmwcmp-emacs-dimmer-0.4.2-checkout for me
<jgart[m]>The former is more descriptive the latter is more terse/concise
<lfam>It's likely that you already have the thing described by the hash in /gnu/store, so Guix does not try to create it again
<morgansmith>I really don't think that's the case. could you humor me and try it for yourself?
<jgart[m]>lfam, could you share the snippet of the implementation?
<lfam>morgansmith: Delete the source checkout and try again
<lfam>The source checkout will not be named descriptively
<morgansmith>ok, it was because my guix was dirty. I did a rebuild and things magically changed so now I do see the correct results which you say. Sorry for wasting your time. I just didn't want to rebuild things :P
<lfam>This behaviour (source doesn't get rebuilt unless the hash changes) can mask issues like incorrect URL
<lfam>Every guix hacker learns about it in a similar way :)
<morgansmith>I was more kinda asking that because I didn't want to assume I was in the right place :P I still don't understand the package structure. It looks like that's what turns URI's into file paths but I'm still not 100% certain
<leoprikler>well, assuming you are in the right place, that would trigger a world rebuild
<morgansmith>I'm not sure what triggers world rebuilds, but wouldn't this only cause packages that currently have the file-name set to #f to be changed?
<leoprikler>well, sure, but those are likely still large in number
<leoprikler>btw. we really need to do `guix moo` at some point
<morgansmith>I'm only now realizing that to automate the creation of the file-name in an origin, the origin now has to know the package name. Something it does not know. I'm not really sure how to overcome that issue :/
<morgansmith>well, at least I learned a few guile things. There are worse ways to kill time
<lfam>I think it's a good learning experience, even if it doesn't lead to patches
<moesasji>in terms of learning experience: can anyone give me a hint on what the correct approach is the add a custom xkeyboard-config? It is clear to me how to create a variant, but not how to add it to the system-config.
<morgansmith>I'm tempted to claim that the filename should be based off the git url and not the package name just so I could make a patch, but I don't think that'd go over well. It's in this odd inbetween where it should be seperate enough from a package to not require information from a package, but is used so closely with packages that we would like it to be named after them. Also if I did try to change the file-name, I think tha
<morgansmith>moesasji: Did you read the manual section 10.2 ‘operating-system’ Reference? All you have to do is give the keyboard-layout field a value
<moesasji>morgansmith: yes read that, but I want to add my own custom layout system-wide. Hence the desire to replace xkeyboard-config
<morgansmith>huh, the manual doesn't have a link from the operating system reference page to the keyboard layout page. Maybe I'll have a patch today anyways
<mdevos>Take a look at (gnu system keyboard), and (gnu services xorg). It seems keyboard layouts are referred to by name, so as it is now, a custom layout would be possible, I think. Unless you want to chose a different than default, but still standard keyboard layout.
<moesasji>I have a patched xkeyboard-config....just need to figure out how I can replace the default version. The manual on variants points to channels, but isn't very clear how
<mdevos>Changing between, say, qwerty and azerty would be simple, but switching the ‘t’ and ’b’ key but keeping everything the else the same seems complicated. But patches would be welcome I suppose :).
<mdevos>moesasj: you can also do ./pre-inst-env guix system reconfigure etcetera, from your locally modified guix
<mdevos>(I haven't tried that, but I see no reason why that wouldn't work)
<moesasji>but doing that goes against having it embedded in my system config.
<moesasji>and for the base system you wouldn't have xorg
<moesasji>I think the answer lies in using 'package-input-rewriting', but I don't see examples that make sense to me.
<mdevos>moesasji: like any other package? (xorg-configuration (server your-customised-xorg-server))
<mdevos>and I don't understand what you mean by ‘and for the base system you wouldn't have xorg’
<mdevos>If you're trying to modify xkeyboard-config, that means there's a probably some GUI, so presumably you're running Xorg? Unless you work on the console only?
<moesasji>if you look at the minimal sysconfig example you can still set the keyboard and that one doesn't have xorg installed. It uses the keymaps installed by xkeyboard-config to set the console layout
<mdevos>Hmm, it seems you need to pass a custom xkeyboard-config argument to keyboard-layout->console-keymap
<moesasji>that is why I went for using a modified source approach as that way my own layout would act the same as any other layout...but now I don't see how to replace the default package in a way I would do that when not using guix
<mdevos>You can add an additional keyword argument #:keyboard-layout->console-keymap to raw-initrd in (gnu system linux-initrd)
<mdevos>that will allow you to use your custom xkeyboard package I think
<moesasji>the system will still need to 'know' about my custom layout in the first place
<mdevos>you can add a custom initrd in (operating-system ...) definition
<mdevos>and set the (initrd ...) field to a procedure that will call base-initrd with your custom layout package
<moesasji>mdevos: I think you focus an the wrong element. I need to get my layout to end up in the correct xkb folder so that the guix tools can use it in the same way as any other keyboard layout.
<moesasji>I think my question is really how one overrides an existing package....that bit is not clear to me from that section in the manual
<mdevos>???, isn't the keyboard layout set in the initrd? Then modifying the initrd to use your own keyboard layout package would do the trick no? Isn't that what you need?
<efraim>cbaines: don't blame yourself, that was past cbaines
<moesasji>you set the keyboard layout by setting those fields, but if you look at the keyboard.scm source you see that it uses the layouts that are placed in the xkb folder that xkeyboard-config populates
<mdevos>Didn't you write a forked xkeyboard-config that includes your custom layout? Then teaching the relevant procedures to use your package variant instead of the upstream package, then these procedures will use the layouts in your package, no?
<moesasji>indeed, but I don't see how to get my package variant to replace the default package (except by hacking it directly in guix source and that seems not the way to do it)
<mdevos>Alternatively, if you don't mind modifying guix code, you could just override the origin in the xkeyboard-config package in (gnu package xorg), by changing the code?
<mdevos>I think I have all I need to write the patches myself, I'll be back later
<moesasji>mdevos I was trying to avoid that approach as it must be possible to do it properly using a channel. Anyway thanks for the thinking and have fun writing patches!
<cbaines>sss2, this might do the trick: guix time-machine --commit=2cb5ebf7a89b59e3e220b837202e4469e1db38c7 -- install pidgin
<mdevos>some changes to guix are sometimes necessary, not all can be done for a channel. But if its something useful to everyone, then there's no reason to keep your code in a channel and not submit it upstream.
<cbaines>sss2, feel free to open a bug about this as well, or I can if you'd like?
<apteryx>rekado_: until a better importer, the following produces the list of paths to pass to the simple-texlive-package procedure: sed -E -n 's|^.*texmf-dist(.*/jadetex/).*$|"\1"|p' $(guix build texlive-bin)/share/tlpkg/texlive.tlpdb | uniq :-)
<apteryx>well, it lacks the non-directory entries such as the man pages
<mbakke>apteryx: I haven't been following the chat lately, what is the context?
*mbakke still needs to rebase their TeX Live 2020 work on top of the recent core-updates changes
<lfam>Does anyone have advice on checking for cyclical module dependencies?
<lfam>I'd guess it's the operating-system in %zabbix-os
<lfam>I guess we should adjusts all the tests, as a followup to the upgrade
<cbaines>with any luck, fixing this system test will allow Cuirass to complete the evaluation
<cbaines>I've implemented comparisons for system tests now in the Guix Data Service, and I'll sort out the page to allow easily doing it between branches, that might help spot that a system test is missing