IRC channel logs
2023-10-26.log
back to list of logs
<VesselWave>attila_lendvai: Thank you so much! I have been asking it too often <redacted>Is it possible to reference my nginx configuration file from multiple places in my guix config? <redacted>Similar to how (local-file "foo.txt") returns the path to /gnu/store/[hash]-foo.txt <redacted>I think I don't grok how configuration blocks get turned into files, which might be why I'm confused on this point. <vivien>redacted, you can run “sudo herd configuration nginx” to see the final file used by nginx <lechner>rekado / fsf whitelisted my IP, but rsync is still asking for a password. does mumi use one? <Kolev>Adding new user to system. Reconfigure takes a long time. <porcupirate>Removing the offload machines from a system config and reconfiguring does not remove the machines file. I think there's a similar problem with substitutes, but I haven't checked. <achow101>ok... now my problem is "no space left on device" when building a derivation, but 'df -h' says I'm nowhere near full <achow101>oh i'm running out of inodes during the build <rekado>Kolev: it will be fast when you use the same Guix as before. Check which guix you’re using. <NewGuixUser>So I think I'm running into a certificate error when trying to build an old version of openssl to get python 3.8.5. Is there a better solution than just manually changing the system time? <rekado>NewGuixUser: is this the build or the tests that fail? You could disable the tests with a transformation. <NewGuixUser>rekado: it was the tests. Everything has been running smoothly since, it's just taking awhile since this commit is old enough that everything needs to be bootstrapped <jpoiret>yeah, some older versions of openssl have time bombs unfortunately <jpoiret>if you're building openssl yourself, you can disable the tests, that might be easier <adanska>anyone running Guix System with GNOME have hibernation working? I added the `resume` kernel argument but loginctl hibernate doesnt do anything. strace shows that its throwing some sort of error, but nothing comes out from stderr or stdout. https://pastebin.com/PsW5ici7 see line 290 <rekado>it would be nice if “guix copy” could also manage remote profiles <rekado>I deploy an application that has been built locally to a remote server with “guix copy” <rekado>this copies all new store items to the remote, but it doesn’t operate on profiles <rekado>I suppose I could then run “ssh remote -- guix install /gnu/store/…-the-new-thing” to update a remote profile <rekado>but that’s a little inconvenient <rekado>I’m looking for something between “guix copy” and “guix deploy” <civodul>rekado: ‘guix package’ could operate over SSH similar to how ‘guix deploy’ does it <sneek>Welcome back civodul, you have 2 messages! <sneek>civodul, rekado says: guix.bordeaux.inria.fr ran out of space while building tensorflow <civodul>another option is to run ‘guix publish’ on the build server <phf>civodul: Hi: It's ok, I've figured it out. <civodul>rekado: re ENOSPC, not sure what to do; can we make sure Tensorflow gets built with -g0 or similar? <civodul>builds start iff there’s at least 5GB free <gabber`>so i've (finally!) managed to get my raspi to boot into GRUB, but now i'm left at the GRUB REPL. any ideas on how i can get the system to boot? <rekado>civodul: is -g0 to ensure there are no debugging symbols…? <rekado>the two outputs of the tensorflow package are huge <rekado>the “python” output is 700+MB because it contains a lot of libraries that are only necessary to finish the build of the python-tensorflow package <rekado>the source code and the vendored inputs both take up a lot of space, too. <civodul>rekado: yes, if it’s C++, debugging symbols take a huge amount of space during the build, on /tmp <civodul>so it looks like the whole thing (source + build result + build tree) may take close to 5GB right now <civodul>anyway, maybe i can adjust the GC thresholds on build machines, too <civodul>rekado: the JS code for build logs was written *cough* by a junior intern, bear with them <civodul>rekado: one of the build machines was quickly running out of space; i found it had lots of stale GC roots, which i’ve now removed <ennoausberlin>Hello guix. Is someone from the python team around? Any chances to pack torchaudio for guix? There is only binary on pypi but an github repository exists <PotentialUser-47>Hi! I am having problems with emacs(-next): with version 30.0.50, org-roam doesn't work correctly: when I try to run 'org-roam-node-find', "Selecting deleted buffer" appears in the terminal. When I run 'emacs-30.0.50 --debug-init', it doesn't start correctly because of an error with org-roam/emacsql: https://paste.debian.net/1296286 <PotentialUser-47>And Emacs 29.0.50 complains that 'seq--take' is undefined. I have no idea where this comes from. As far as I understand it, it should be 'seq-take' and part of Emacs. <phf>Hello #guix! So, I've got enough code (https://paste.debian.net/1296287/) to have `./pre-inst-env guix build elixir-machete' to build, tests inlcuded of course (Elixir packages rarely include tests). <phf>It is also my first time writing Guile code. <phf>I also have about 70 more Erlang and Elixir packages on the back burner, possibly enough to get Phoenix to build. <nckhexen>If it's a Guix system, and you've configured GRUB as its bootloader, it will have created a /boot/grub/grub.cfg. Find it (manually using ’ls’, or try an automated ‘search’) then load it with ‘configfile FILE’. <nckhexen>I'm assuming this GRUB is healthy and not a rescue> prompt. <gabber`>nckhexen: Raspberry 4 Model B (i've posted to help-guix@ a couple of minutes before but i guess my email hasn't been forwarded to the list yet) <gabber`>there is one grub.cfg in /efi/boot/arm64-efi/grub.cfg with only one line: "source efi/boot/grub.cfg" (which doesn't exist) <nckhexen>I'm pretty sure it's /boot/grub/grub.cfg. <nckhexen>Well, that was before I read the ‘image’ part, I'm not as familiar with those. <gabber`>i'm sure it *should be* -- and that's probably the reason why it won't boot <gabber`>but thanks, that's a good pointer to go after <gabber`>it definitely is: it touches pretty much all the boot-loading topics (U-Boot, EFI, GRUB, ...) which inspired me on writing a blog post on the topic <gabber`>... and we boot (manually, but still!) <nckhexen>Should be ‘trivial’ to add a <the *other* other partition>/grub/grub.cfg that configfiles for you, to continue this trend of cursed chainloaders. Should. <gabber`>i'm sure i'll find a way. as long as it boots automatically i'll be happy™ <mirai>what's the correct term for the kind of result obtained from a system-test? <mirai>it returns a /gnu/store/… thing <mirai>not exactly a gexp, I'd say it's whatever you get from building a gexp <civodul>though actually <system-test> records are “lowerable” (just like packages, operating systems, etc.) <civodul>meaning you can insert them in a gexp <mirai>I just finished posting to guix-devel about expressing dependencies between system-tests <mirai>if they can be inserted within a gexp perhaps I can use it in the meantime for that <gabber`>does #:hooks in efi-bootloader-chain refer to a simple lambda? or a lambda in a gexp? <apteryx>(the user provides a list of dependencies as actual Guix code in the hall.scm file, and the generator of the guix.scm output should ideally add the correct #:use-modules for these dependencies itself. <apteryx>I think it's this way to avoid requiring Guix libraries installed to generate such file; but I'm think to implement the feature conditionally when guix is available <civodul>apteryx: one can traverse bindings exported by (gnu packages …) modules and get the variable/package mapping <mirai>is (specifications->packages …) insufficient? <apteryx>ah, I wasn't thinking about such an approach <apteryx>mirai: yeah, that's what I was thinking to do, warning in case it fails <apteryx>e.g. someone used a variable rust-something-4.3.2 but the package name is "rust-something". <civodul>apteryx: it’s definitely possible to obtain, given a package “spec”, its module name and variable name (if any) <gabber`>nckhexen: your idea was to create a /grub/grub.cfg on the partition that grub already mounts as /, right? <civodul>Hall should be able to generate the right ‘define-module’ stanza and refer to the right variables <apteryx>actually I was thinking to use package-name->name+version and find-packages-by-name (this is what 'guix show' does) <apteryx>civodul: the problem is that the input is not a "spec", it's a code <apteryx>so the user would use actual guix variable bindings <civodul>so Hall sees <package> values, right? <apteryx>that's not a very good design, perhaps, but that's how it decouples hall from guix I guess <apteryx>you have to give it the dependencies as in the old guix days: `((hello ,hello) ("guile-lib" ,guile-lib) ...) <apteryx>in your hall.scm file, which must be read as data <civodul>and then Hall just pastes that as-is in the generated guix.scm? <civodul>without depending on Guix, that’s the only thing it can do <apteryx>and doesn't try to adjust the #:use-module list; it simly has a useful hard-coded template for it including guile and guile-xyz <civodul>if adding a dependency on Guix is acceptable, then it can get accurate data via the Guix APIs <apteryx>yes; I'd like to try to autoload (gnu packages) and gather the package locations as a best effort <apteryx>does that sound reasonable? it's the least invasive change I can think about, that should provide some benefits <apteryx>perhaps I could also accept Guix package specifications in the hall.scm file when Guix was found <apteryx>maybe in a new field would be cleaner <apteryx>then I can error if that field is used if Guix is not available, and otherwise have guaranteed good results. <civodul>that introduces a dependency of Hall on Guix <civodul>whether that’s acceptable, i don’t know <apteryx>it'd be optional; don't want it, don't use 'dependency-specs' <civodul>but at least it would ensure that it generates valid code <podiki>so I'm finally trying to use geiser, and my first try of M-. nothing happens :( or it freezes which I see guile doing something in the background, even after it completes nothing :( <podiki>apteryx: me? it was a built checkout of guix but doing a git pull and rebuild now anyway <apteryx>podiki: yes. when there are lots of files to evaluate it becomes unresponsive <apteryx>byte compiling everything should help <podiki>it did finish eventually but still did nothing; let me see after a fresh build <apteryx>Also, you need to start the REPL before navigating; Geiser warns about it <apteryx>I typically use C-c C-a to load the module I'm looking <podiki>and on the topic, anything special that needs to be done for external channls and using geiser? for an external channel had some report needing to set geiser-binary to "guix repl" otherwise it was out of date guix? (investigating now) <podiki>alright now it goes to the module at least in guix checkout when using M-. <ekaitz>hi, in a cross-compilation to a different machine is there any way to jump inside a failed build dir and continue manually? <ekaitz>with -K i can keep the directory but I don't see any comfortable way to jump in, in a virtualized container <apteryx>can I get the variable name of a package given its spec? <apteryx>ekaitz: sourcing environment-variables there is not enough? <podiki>gabber`: thanks, but didn't seem to be needed actually, works on my end... <podiki>thanks all; seems a fresh build of guix checkout did the trick <ekaitz>apteryx: also, even if it did, i don't think it would jump to the target arch <podiki>though M-. only goes to the module when trying on a package name, is that expected? <apteryx>ekaitz: cross compilation means building for a different target using a cross-compiler. sourcing '. environment-variables' should be enough to get the cross-compiler to work <apteryx>(if I understand correctly what you are doing) <ekaitz>apteryx: guix build X --system=riscv64-linux <apteryx>that's not cross-compilation; that's building natively on a riscv64 machine <ekaitz>i just realized that when i said <apteryx>np. in this case connecting to that remote riscv64 machine, going to the failed build and sourcing environment-variables should do it <ekaitz>apteryx: but the remote machine is my machine in qemu <apteryx>but you can't -K and offload at the same time (-K implies local), so you'll have to resort to GUIX_DAEMON_SOCKET=ssh://your-riscv-host ./pre-inst-env guix build package-x -K <apteryx>so it's not remote :-) it's building via QEMU user emulation locally <apteryx>then the failed build should be local, and sourcing . environment-variables should be enough <apteryx>the rest will happen by the same binfmt registration magic <ekaitz>`environment-variables` is empty <apteryx>this you need to figure out why; does the build fail early? <ekaitz>that might be the source of the problem <ekaitz>but still, i'm building several dependencies and they go alright <ekaitz>and i found the same thing in them too <ekaitz>and it's failing in the build step <apteryx>ACTION checks at importer to see how we generate package variable names for package objects <apteryx>so we expect the package name to match 1:1 with its variable name <ekaitz>apteryx: in packages with different versions that's not the case most of the times <gabber`>how can i install a file in the efi part of my first MBR partition? i tried an mkdir-p which fails (permission denied) <efraim>ekaitz: it might be a qemu bug. I can try building it on real hardware later <efraim>I'm currently at a conference but I can get it started after I get back to my hotel tonight <ekaitz>don't go like running to the hotel to do this, it's not that important <podiki>efraim: what's the latest on the rust-team branch, is that to be merged on a regular interval? (there's a patch to add rust-cbindgen-0.26 I was looking at, but then just saw a separate commit on rust-team already) <efraim>Basically whenever I get around to it. I was hoping to be more active with it <efraim>I didn't look at what commits I could cheerypick back to master <podiki>seems all inputs are same version but I can double check it builds <podiki>any preference on the cherry-pick or the other patch that does an inherit for 0.24? <efraim>I don't have a preference between the two, either way it should be deduplicated after rebasing the rust-team branch <podiki>alright. i have 66729 already locally so I'll just do that after I double check. thanks! <pastor>Te problem is that from this repo multiple crates are generated. Since I need a newer version I cannot use the old crates from crates.io. <pastor>I guess I should make multiple packages. On the origin reference is it possible to take only a subdir of the git repo? <rekado>pastor: SVN was able to do this; git doesn’t let you do this. <rrobin>don't know if you can include subdir in the origin, but worst case you can chdir on a phase <rekado>so you’d define one package with that origin and add a phase to chdir <rekado>then the other packages inherit the same origin and chdir elsewhere <pastor>rekado: changing dir on one phase changes the dire for the subsecuent ones? <rrobin>yes it changes for the following phases <pastor>Alright. That sound acceptable enough. Btw I was wondering. For this package for now I'm having more that 2k lines of rust packages. Do I have to make all the packages compile? They seem to work when used in the `#:cargo-inputs` even if the don't compile individually. Many are from `guix import` <pastor>rekado: If I do the chdir. How is it going to work for `#:cargo-inputs`? Won't the whole directory be inserted as a crate instead of a subdir? <pastor>maybe I should replace the unpack phase and do some hacks leave only the sources I need? <pastor>Ah no. They require dependencies from the other modules on the same repo... <nckhexen>gabber: That is what I meant (so GRUB's $prefix, since it doesn't quite work the way a Unix system does, although it heavily borrows from its… aesthetics). <nckhexen>I don't really understand your ‘insert a file in the efi part’ question. <jackhill>Hi, I'm trying to run a python program (ansible) from a relocatable pack on CentOS 7. However, it prints this error instead of running "ERROR: Ansible could not initialize the preferred locale: unsupported locale setting" Thoughts? <lechner>rekado / Hi, FSF whitelisted my IP, but rsync is still asking for a password. does mumi use one? <philip>Could someone take a look at nghttp2 (https://issues.guix.gnu.org/66658)? I don't feel like I know what I'm doing with grafting, especially, so the patch may be completely wrong, but I thought someone should address CVE-2023-44487. <podiki>philip: that's the right idea from my quick look, though probably a name like nghttp2/fixed is more conventional (but not fully established) <podiki>philip: I assume you tested that it builds? and for abi compatibility/running a dependent that gets the graft? <podiki>philip: since such a version change might indicated other changes (in build, in usage) <podiki>"guix repl" use guix and guix's package definitions from the current user (i.e. latest guix pull version) right? while GUILE_LOAD_PATH is for the current system configuration? <podiki>trying to set GUILE_LOAD_PATH to be e.g. a guix checkout doesn't change anything? i'm confused <podiki>confused over how guix's modules are loaded by guile in general, I'm missing something <mekeor>podiki: perhaps missing %load-path variable? <podiki>ah figured it out, you need both GUILE_LOAD_PATH and GUILE_LOAD_COMPILED_PATH <podiki>i just assumed (yes yes, we know what happens) that the compiled path was just for speed but I guess not? <podiki>...or not. i'm confused over what is working or not here :| <podiki>ignore the comment about compiled path, i think it is just to use compiled stuff; some other thing over here....ignore me now :) <mekeor>wtf, i have a local package declaration, which gets its source from gitlab.com, which now requires me to log-in in order to access the source! <mekeor>i wonder if this breaks the process of building (more precisely, downloading) packages for cuirass-instances like ci.guix.gnu.org and bordeaux.~ <nckhexen>If the source isn't substitutable or mirrored, then yes. <mekeor>i.e. gitlab.com is a very bad source-source? <podiki>i think my conclusion was that you should extend GUILE_LOAD_PATH don't just replace it, as there are some bits in the system's profile you miss out on <podiki>and you get "no code for module" errors <podiki>gitlab should be fine, but maybe the repo went private? <nckhexen>mekeor: Uh, you lost me there. Why would that be? <nckhexen>I mean: what's so special about gitlab.com? <mekeor>nckhexen: let me tell you my story. have a local (package ... (url "gitlab.com/...")). try `guix install it`. get an error that it can't be downloaded. try to open url in the browser, which states: "gitlab.com needs to review the security of your connection before proceeding. Please unblock challenges.cloudflare.com to proceed." <mekeor>i never experienced github.com or sr.ht to require a log-in to access code. <nckhexen>Whoakay. I thought you meant the repo had gone private. <nckhexen>GitHub rate-limits things (‘guix refresh’ has a whole code path to deal with this) but I don't think it limits clones, although I wonder if it will if it thinks you're ‘suspicious’. <mekeor>well, i'm not sure if this is relevant, but after logging in, i saw that the repo had been deleted (and moved to sr.ht) <Lumine>mekeor: maybe cloudflare is being a clown <jaeme>Which package provides the ~uname~ program? <podiki>i've seen the cloudflare for gitlab in the browser but never saw an issue with a git checkout <nckhexen>mekeor: GitLab's way to 404 is to prompt for a log-in. <podiki>jaeme: guix locate tells me bash and coreutls <nckhexen>I think it's well-intentioned, to prevent information leaks in some (edge) cases, but it's confusing. <mekeor>for me, it's /gnu/store/yr39rh6wihd1wv6gzf7w4w687dwzf3vb-coreutils-9.1/bin/uname <mekeor>feel invited to share your coreutils' hash <mekeor>and yes, /gnu/store/…-bash-5.1.16/lib/bash/uname exists -- under /lib! <jaeme>Should I include the nss-certs package as an input? <podiki>ACTION goes to run, literally, after too much confusion over guile load paths... <nckhexen>Damn it, I *knew* about that lib uname, but I forgot >:( <jaeme>mekeor: I want to be able to enter a pure guix shell with working ani-cli <nckhexen>jaeme: No, it should be provided by the OS, it's a bit of a special case (maybe? depends on your perspective) in that regard. <mekeor>jaeme: do not put nss-certs in inputs <nckhexen>It's fine to add it for your own convenience but saying that it ’should’ be there is false. <nckhexen>(So remove it when you submit it upstream.) <mekeor>yeah, imagine a user of ani-cli watches only animes from a server that does not require https <nckhexen>I think the best argument/logic here is that certs are a ‘state of the world’ thing, like timezones, which shouldn't be locked in functionally as if they were software. <nckhexen>There's also the argument that users/admins should easily be able to untrust them. <nckhexen>There have been some dodgy certs in nss-certs. These are eventually removed but it can take time. <jaeme>nckhexen: Interesting. I'll def keep note of that. <jaeme>Where should I place ani-cli in videos.scm? <jaeme>videos.scm is not ordered alphabetically <nckhexen>I put new packages above the first package that would come after it alphabetically. Which sounds more complicated than it is. <jaeme>If I import more modules for the packages, how should I declare that in the commit changelog <jaeme>I add (gnu packages bittorrent) etc to the #:use-module chain <jaeme>How about updating the copyright header? <nckhexen>Also nope. Hey now! Don't get the wrong idea! Our changelogs *are* pedantic! Promise! <nckhexen>In general, unless the entire commit is only about fixing/modifying/… a comment, I don't mention comment changes at all. <jaeme>Okay I submitted my revised patch to debbugs, this is a lot of fun lol. <jaeme>I can't believe anime was one of my first patches smh <nckhexen>I think my first-ever patch to Nix was enabling the insults to sudo 🤷 <mekeor>jaeme: i love it :) i'm looking forward to try ani-cli :) <mekeor>ACTION needs to try out `guix publish` in order to use the performant work-computer to build packages for the personal-computer; in particular emacs-yaml somehow needs ages to build <Kolev>Guix frustrates me. `guix pull` takes forever, for example. <mekeor>nckhexen: guix does not ship sudo with insults, right? <mekeor>Kolev: i agree. guile and guix need performance improvements. <rekado>Kolev: are you using channel-with-substitutes-available? <Kolev>rekado, I have substitutes enabled, if that's what you mean. <rekado>no, I’m asking about channel-with-substitutes-available in your channels file <rekado>because that will only pull guix up to a point that has successfully been built on the substitute servers <rekado>so you don’t need to compile any of the “guix pull” derivations locally <rekado>all the work that then remains is to compute the initial derivation (that’s a little slow) and to download substitutes <mekeor>(although it's more verbose than needed, since %guix-default-channel or so exists) <nckhexen>mekeor: I update sudo several times a year, unfortunately this has included security updates. <nckhexen>ACTION is reminded that opensmtpd was updated, so thanks, indirectly. <mekeor>nckhexen: perhaps try guix package -i sudo --with-configure-flag=sudo=--with-all-insults etc <mekeor>nckhexen: if you want sudo to insult you <nckhexen>Ah, thanks :) I already use a custom sudo package. <mekeor>nckhexen: oh, why? security improvements? :D <gabber>may i propose sudo-with-insults (or should it rather be named insulting-sudo?) <mekeor>gabber: or should it be another output of the sudo package? <nckhexen>It's a different build, so can't be an output. Also, it would suffer the same fate as fortune-mod, a long ML thread followed by reversion. <nckhexen>mekeor: Don't worry, I'm not hoarding sekrit security fixes for myself. It's mainly historical, and I could probably do without it, but I used it to enable the Python integration which I played with for a while. <mekeor>maybe that thread would satisfy the need to be insulted <gabber>is the winning argument GNU communication standards being against humor (i'm about 30% kidding, i actually like that standard) <civodul>any Home user here? we desperately need active reviewers on the ‘home’ team <Altadil>civodul: do you mean the guix home command ? <Altadil>I do use it (more than guix install actually), so I there is a need for testing I can help (but I lack the experience for actual package review :( <civodul>i think we need fixed-term mandates on teams, it cannot work if membership is sloppy <rekado>oh, that’s a nice service! Just today I was wondering whether we have one. <civodul>two candidates on the ‘home’ team in 5mn, not bad :-) <gabber>not super keen on the home-team membership (or review that patch in particular), but have i never sent my patches to create an audio team (and add my self to that)? <Altadil>civodul: yes, I am actually in the learning process for packaging (well rather I should get back to it when I have some time ^.^) . I’ll keep in mind that there are teams in need of reviewers. Is there a way to see which are understaffed ? I guess just the number of members is not a good indicator. <gabber>ACTION can't find a hint of these patches on issues.g.g.o so they'll rebase and send'em <civodul>Altadil: the numbers and the actual activity reviewing patches in the team’s scope <civodul>gabber: if even you don’t know whether you’re on a team, we have a problem :-) <gabber>i knew i was not on the team (since i checked the sources) but i was at least 30% sure (yes, that's a lot) that i sent the patches (since i had crafted them -- and mentioned them to somebody somewhere?) <Altadil>civodul: thanks. I can’t do much now, but I’ll remember to check that once I’m more able. <apteryx>civodul: seems in latest version of hall, you can declare dependency on guix via (features '((guix #t) ...)) in the hall.scm spec file <podiki>speaking of teams, I need to create one for mesa and friends. graphics? <gabber>is tonight the night ... where we all create and join new teams? <podiki>the tricky thing is scope, maybe we can see about extending the teams code to take a list of packages? and then anything touching those or dependents of could be cc'ed in git send-email? (maybe too tricky?) <podiki>ACTION also needs to send an email about a mesa-updates branch and start cranking on that <gabber>nckhexen: did you need much more system configuration magic to replace the %base-packages sudo with your custom one? more than adding your package to the config and to setuid-programs? <nckhexen>gabber: No magic. I just added sudo/nckx to my list of privileged-programs (my equivalent to setuid-programs), didn't bother adding it to packages because the man page/bash completion is functionally identical. <gabber>and you also didn't remove it from the system's %base-packages? which works because in $PATH your personal profile comes before the system's?