IRC channel logs
2024-05-05.log
back to list of logs
<rekado>bdju: there's a bug report about it and a patch was submitted, but the patch doesn't actually address the problem. <rekado>I tried to compare wip-python-team (1b5f0997501533266c1895b9574d34b90b4ea438) with some previous commit on master (5010a51fc91aeac5a3b87a3eea04f18f3fe8a3a3), but no matter which commit from wip-python-team I pick the Guix Data Service says it doesn't know it. <dcunit3d>is there a good way to get guile to ignore modules within a specific subpath? I have Guix packages/services in ./ellipsis and ./dc, but a few modules with packages I'm working on in ./ellipsis/packages, but a lot of these either require me to stash, save patches (via magit) or create branches, which ends up creating a mess that's hard to remember <dcunit3d>can i just create a module within like ./ellipsis/packages/wip/my-golang-package.scm and then ignore the entire ./ellipsis/packages/wip subdirectory? I'm not sure how to do that with GUILE_LOAD_PATH. or should I move it outside of the ellipsis namespace entirely? <dcunit3d>no modules/packages would refer to any symbols in these WIP packages <dcunit3d>for now the modules are in my dotfiles and tracked in git. the `.` folder would be the root. i may either create an orphan branch or another git repo entirely, adding to the LOAD_PATH as necessary, then changing references as I pull things in. normally to exclude the files, i just rename the file extension from .scm or create a diff... but is there a way to do this in Guile's modules system? it's fairly tightly bound to the file system <Tadhgmister>you could make a symlink to the thing you are actually working on somewhere else and use that as the load path, I know that is what I did when I was transitioning my messy folder of broken scheme files to actual modules <Tadhgmister>when I use `customize-linux` and pass a config option that conflicts with the default for guix it throws an error, what is the correct way to override something from the default? <dcunit3d>Tadhgmister: that may work, but i think it still needs a different path for the module root. i guess let me see what happens when there's an invalid symlink <Tadhgmister>dcunit3d: `mkdir -p /tmp/guile_load/me/; ln -s /home/me/src/dotfiles/packages /tmp/guile_load/me/packages` then add `/tmp/guile_load` to your load path <Tadhgmister>oh I guess you probably have files further up the directory tree that you also need? <dcunit3d>Tadhgmister: there is also GUIX_PACKAGE_PATH which i think is fairly new <dcunit3d>this does seem to work, even when /tmp/baz doesn't exist: `env GUIX_PACKAGE_PATH=/tmp/baz:/home/dc/.dotfiles guix build notabin-package` <Tadhgmister>but you have `/home/dc/.dotfiles/ellipsis/packages/wip/...` right? so it is still going to see your WIP files <dcunit3d>i guess my main problem is estimating the level of work required to satisfy a golang or rust package's dependency tree or whether matching the minor versions matter. also, upgrading some dependencies for mulitple package definitions isn't so easy. in some cases, guix transformations can be used (I think) to create a derivative package for an alternate source. however, simply avoiding this to one (my packages golang) module when it's <dcunit3d>usually in the load path may create problems for extant golang/rust packages (or result in re/naming issues later) <dcunit3d>Tadhgmister: yes. i think I'm just going to move them elsewhere, use org-babel to tangle what's needed to build a single package, build them with GUIX_PACKAGES_PATH specified, and then bring them into my dotfiles project when there a minimal issues. <Tadhgmister>dcunit3d: I guess the part I'm not understanding is why putting them there is an issue if they are still syntactically valid, like if the code there doesn't get close to successfully building but is valid scheme code why is having it on the load path bad? <dcunit3d>because I want the majority of warnings/errors to be meaningful & corrected. for now, I'm just ignoring them because there are too many. <dcunit3d>for now, they don't cause problems unless I specifically build one whose original package definition caused an error, but it's just sloppy i guess <dcunit3d>what i may do is move my (ellipsis ...) modules out of my dotfiles project, keeping the (dc ...) modules there, since they are tightly coupled to my own environment/processes. i have a channel project set up and i may use it eventually, but i could also set up an alternate git worktree. here, i could either use an orphan branch or not -- if so this would define a completely separate module subspace (ellipsis ... wip ...). then I can <dcunit3d>clone the channel to a worktrees checkout and when I want to use WIP content, i just ensure that it's ordered properly in the GUIX_PACKAGES_PATH. <dcunit3d>i don't believe I want to operate a channel though. it would be more useful if I helped with someone else's channel or just submitted patches. I haven't built much that I think others would find useful. <Tadhgmister>if you are building free software that is not currently packaged for guix I'd suggest you contribute even if you don't think many people will use it <dcunit3d>Tadhgmister: i would agree mostly. there are some things i use which i don't think would be good additions regardless of the project's level of freeness. <dcunit3d>for various reasons (like maintainence overhead, etc). more packages is not always better IMO. usually these are fairly esoteric things, like tree-sitter-tcl, which is simple but builds from a sourcehut HG repo. <dcunit3d>however for rust/golang, i just don't understand the ecosystem well enough to propose changes to dependencies shared by many packages. <dcunit3d>unfortunately, most golang projects i've tried to build have go.sum files which indicate quite a few custom/forked dependencies. there are a few places in Guix source/packages where I see examples using/maintaining multiple package versions, but in some cases this can be more effort (or build resources) than is worth it. <Tadhgmister>ah I see, you are changing existing packages to get your own stuff working but probably not in a way that would be appreciated to everyone <dcunit3d>yes, that's like 80% of what i'm doing, though I hope I could produce contributions when it would be valuable <dcunit3d>so i recently packaged gnupg2.3 and now I need to package gnupg2.4, but the upgrades to these minor versions are contentious in many distributions. however, their compatibility & tooling for smartcards is much better. so I don't think it would be helpful to push these up <dcunit3d>i did submit a package for emacs-x509 though, which had been pretty helpful to me. i got the project owner to put a license on it. <dcunit3d>someone else moved it across the finish line though <freakingpenguin>I did have some annoyances with gnupg 2.2 a while back, basically had to completely disable the smartcard reader to use a yubikey. <Tadhgmister>where is the srfi-1.scm file that is mentioned in backtraces? <Tadhgmister> 5 (primitive-load "/gnu/store/r7bdp1779pqbw2alr3pxyh5fgqa?") <Tadhgmister>I just want a linux kernel for arm that has `CONFIG_PCIEASPM` unset, using customize-linux routine on the standard `linux-libre` fails because that flag is set in the default config and it is apparently an error to change anything already set? <Tadhgmister>and `linux-libre-arm-generic` doesn't seem to have the modules for usb-storage enabled that `guix system` is trying to pack into the initrd <dcunit3d>Tadhgmister: sorry, i was afk, did you figure out the srfi-1 stuff? <dcunit3d>if you're in emacs and have a Geiser repl set up for that buffer, you should be able to navigate to definition with xref <dcunit3d>for me, the srfi modules are sourced from the last directory in %load-path (./share/guile/3.0/srfi/*.scm) <Tadhgmister>I need to install Geiser, I think I figured out the issue and understanding exactly where in the backtrace it was happening wasn't super important <KindlyRepeat>For anyone reading this, by default, gnu shepherd store its log in /var/log/messages for services started as root. I believe this is set by %default-syslog.conf <KE0VVT>efraim: Are you back from vacation? <efraim>I'm at libreplanet today and tomorrow, back home next week <wakyct>KE0VVT, I thought I saw that you got that package successfully added to your system with a reconfigure? Maybe I'm remembering wrong <KE0VVT>wakyct: I did, yes! :-) Sadly, audio still shows up as Dummy Output. <KE0VVT>efraim: Which talk are you looking forward to most tomorrow? <rekado>dcunit3d: GUIX_PACKAGE_PATH is ancient. It's what we used before we had "guix pull" with channels. Now its only purpose is to extend the load path. <zilti>My GDM broke the last update. The workaround is very bizarre: I log in on another TTY with my personal account, run `sudo killall gdm` to which I get the result "gdm: no such process found", switch back to the gdm that is still running, and then I can log in. <zilti>Also, is anyone else here using nix (probably with direnv) on top of guix? That is broken for me as well, now. It is using curl which tries to look for a certificate in /home/zilti/.guix-profile/etc/ssl/certs/ca-certificates.crt, but the right path is /etc/ssl/certs/ca-certificates.crt <zilti>Curl itself, when used directly, is broken as well - failing for https with "curl: (60) server certificate verification failed. CAfile: /home/zilti/.guix-home/profile/etc/ssl/certs/ca-certificates.crt CRLfile: none" <jpoiret>zilti: wrt gdm, is switching to tty2 then back enough, or do you need to also login? <jpoiret>I'm assuming the killall doesn't actually do anything <jpoiret>Wrt the second question, that's Guix's curl, right? <zilti>jpoiret: with gdm, no, I tried switching back after just switching, after logging in, and then again after issuing the useless killall, and only after the latter it worked. Maybe it was just the repeated switching? <zilti>jpoiret: Yes, that's guix's curl <jpoiret>zilti: wrt curl, what's the link with nix? <zilti>jpoiret: In the "curl itself ..." example, no link at all. In the second, it's that nix-shell is using curl internally to download the package channel <jpoiret>but wouldn't nix-shell use nix's curl? I'm not familiar with it <jpoiret>in any case, you can add nss-certs to your profile to get the certificates <zilti>jpoiret: Hm. I assumed I wouldn't need nss-certs in my guix home config anymore now that it is part of the base system, but I will try that <Tadhgmister>I am so confused..... when I cross compile glibc-mesboot it fails at setenv because something being passed to string-append is the wrong type..... but when I edit the package to just print out some of the variables it compiles fine??????????????? <Tadhgmister>wait no.... how do I ensure my git repo is pointing to the same version my system is currently using? <Tadhgmister>like how do I find the commit of guix that my system is uusing? <Tadhgmister>it wasn't succeeding like I thought, it was building the non cross compiled version in order to build the other dependencies to do the cross compile <theesm>unstable-horse: seems down to me as well right now <poplin>Hello everyone. I'm trying to start with guix. I was wondering if you know/can recommend some tutorial with some basic templates for config.scm and home.scm. <Franciman>i think you can find some examples in the cookbook. regading config.scm, the installer asks you questions and then prepares one for you <Tadhgmister>if I want to convert markdown into html would I likely use pandoc or is there another easy-to-install-with-guix package I can use? <Tadhgmister>oh nevermind I just found the `--template` option with pandoc that suits my needs <poplin>Thanks both for your cookbook suggestion. Ill give a look. I was just using the qcow image, and once running I cannot find any config.scm. (is there a way to generate it from the running system?) <Altadil>poplin: it’s default location is propably /etc/config.scm <poplin>Altadil: thanks. It was my first guess, but there is nothing there. Even more, using find command there is no config.scm at all :/ <Altadil>poplin: then guix system describe should give you the location where the currently used config is kept in the store. <KE0VVT>I never use /etc/config.scm. I keep my config in a Git repo in my home directory. <peacememories>hiya :) I'm very new to guix (currently running it on ubuntu 24.04 and nixos 23.11) and have some questions/issues ^^' <peacememories>one is that `guix shell -C` seems to fail with a permission error: <peacememories>guix shell: error: mount: mount "none" on "/tmp/guix-directory.GqwOkE": Permission denied <peacememories>I assume that I haven't configured something correctly, but I though maybe some of you've seen this error before <wakyct>how did you install Guix peacememories? <peacememories>i *had* it installed using apt (and then a guix pull), but ran into problems when trying to modify a guix package, so i uninstalled and reinstalled everything <freakingpenguin>Is it possible to add a validator/sanitizor to an record-type* value? I know you can sanitize individual fields, but I'm curious if there's a way to validate the entire record. <freakingpenguin>For example to enforce that two mutually exclusive fields aren't both set to #t <peacememories>regarding the container issue - should I send a bugreport to the guix mailing list? or is that something that's not really interesting to them because it's most likely caused by problems with a non-guix system? <freakingpenguin>peacememories: If you're not sure if it's a bug you can always post to help-guix <peacememories>side note there - do the mailing lists support attachments? or should i post long logs (e.g. the strace log) as a link to a pastebin or something? (I've never really used mailing lists much. I kind of prefer it over Github issues to be fair, but I'm pretty green when it comes to the etiquette etc ^^') <wakyct>I think that depends on the configuration of the maillist peacememories, in practice though I don't see many attachments so a paste might be best <wakyct>though OTOH people might just prefer it in the email? dunno. <wakyct>then they don't have to link out. <peacememories>I've found a few bug reports that *may* be related, but I haven't been able to extract anything useful from them due to my own lack of knowledge about both guix and apparmor. I'll try disabling apparmor before sending the mail, though <jpoiret>usually attachments or in-line are preferred to pastes, since they don't last <peacememories>whoops, restarted to test out some apparmor stuff. I got it running - for now - by creating an apparmor profile specific to the current guix executable. That's probably going to break every time guix is updated though... <graywolf>Is there a nice way to concatenate content of two file-likes object into a third one? <civodul>you have to write a computed-file that opens and dumps both <rekado>looks like wip-python-team does a little better than the master branch, so I think I should merge it now. <jpoiret>civodul, apteryx: I've just sent a mail about c-u's status <jpoiret>more specifically, I think we should drop the pkgconf switch for now <civodul>i thought we had reached the opposite conclusion just a week ago though <jpoiret>I highlight the reason why in the mail <civodul>ok, i should read your message first :-) <jpoiret>also, we'll need to add all the new glibc patches :) <civodul>jpoiret: are you available for hacking the coming week? <jpoiret>2 days of biking around the end of the week but otherwise I'm free <civodul>(something along the same lines for me)