IRC channel logs
2023-05-02.log
back to list of logs
<cedb>im tinking of proposing guix to manage a k8s deployment with docker images, each image being potentially built using multirepo source code (as you can imagine its a maintanability nightmare, hence guix) <porcupirate>I'm trying to block a list of domains alongside the block-facebook-hosts-service-type. I'm getting the following error when I try to build the config: <porcupirate>guix system: error: more than one target service of type 'etc-hosts' <cedb>looks like i can sort of figure it out by reading the manual but its pretty involved in terms of onboarding other people, are there examples of projects that do this sort of src code building/packaging + OCI "image" creation out there, just for a reference point <porcupirate>Now I'm seeing an error, "duplicate 'hosts' entry for /etc" when anything that could possibly be modifying hosts is commented out. <podiki[m]>kaelyn: oh wow, doing the hard work of combining the different ones too, at first glance that looks nice and clean <podiki[m]>kaelyn: I'll give it a look over, try it out locally, and then see how we get cuirass to build a branch for wider testing (I'm assuming I can create the branch but I don't have cuirass access so we'll need someone to create the job I think) <podiki[m]>feel free to follow up/start a new thread on guix-devel or we can wait to get the branch built <floraxgord[m]>“Would you like to discover how to profit from the cryptocurrency market if YES I’m willing to help 11 people how to earn $100,000 in just 72hours Dm me to know HOW on TG. <nathan-web>Hi. When trying to `guix upgrade` I get an error: ` guix upgrade:error: reference to invalid output 'lib' of derivation '/gnu/store/<....>-gcc-toolchain-11.3.0.drv'` What might be causing this? <nathan-web>The upgrade says gcc and gcc:lib 12.2 will be removed and gcc-toolchain and gcc-toolchain:lib 11.3.0 will be installed. <Altadil>Hi, I’m trying to build guix, following the instructions in the manual. During the make check, it seems like it hangs after "PASS: tests/guix-pack-localstatedir.sh". Is the next step expected to take a very long time ? Or is this a bug I need to report ? I tried running "make check SCM_LOG_DRIVER_FLAGS="--brief=no" VERBOSE=1", but it did not give more information. <civodul>Altadil: hi! i might be that one test is taking a lot of time; you can figure out which one it is by running "ps aux" or "ls -lrt tests/*.log" <civodul>a bit of a hack, but that can be helpful in such situations <civodul>then you can look for hints in the correponding .log file <Altadil>Thanks ! It seems tests/guix-pack-relocatable got stuck on building a proot-static-5.3.0.drv… whatever that is. I guess it’s well above my skill level. ^.^ <sepi>Is it possible to have a local bare repo as a package source? I get an error message when specifying a file:/// uri <evilsetg[m]>sepi: You can use the -L or -f command line options. With -L you specify a directory that contains files with package definitions and with -f you can add a package that a file evaluates to. <sepi>evilsetg[m]: I've got that setup working, the problem is that I want to specify a local package source, ie. the source code of the package (not the scheme guix package definition) is only available locally and not via http or the git protocol. <jpoiret>oh, but thanks for mentioning proot! <jpoiret>it is currently broken, I have sent patches upstream for some tests that are hanging (well, they're execv'ing in a loop rather) <jpoiret>but there are some additional broken tests that I don't know how to resolve yet so I haven't done anything else <jpoiret>the broken tests shouldn't really be disabled since they really are symptomatic of some bug <PotentialUser-85>Hello. I got a project from another team and I want to try to build it reproducible. Unfortunately it is a java project and gradle is used for the build process. I left Java almost 20 years ago (Makefile were a thing than). I can not find a guix gradle package and the official instructions to build gradle from source are somewhat spare. Are there <nutcase[m]>Hi, can anyone provide me an example of a (service screen-locker-service-type... ) for swaylock? <rekado>PotentialUser-85: it’s a bootstrapping problem IIRC. Gradle needs gradle. <gabber>aloha! is etc/teams.scm not part of the main Guix upstream repo? i'm trying to create a patch (for a new team with myself as the member) <PotentialUser-85>rekado: I was afraid of that. So I will replace gradle with Makefiles or Ant / Maven <sepi>How can I make sure that the process I launch from a shepherd service has the right pythonpath set to have all its dependencies available <gabber>ahh.. so etc/teams.scm is generated from that? <civodul>and it seems evaluations are now getting stuck <gabber>do i actually have to sign a commit in etc/ to create a patch to add a new team? i seem to fail creating a commit (i might not have set up GPG properly as of now) <rekado>gabber: if you don’t have commit rights you don’t need to sign. The person who applies and pushes your commit will sign it. <rekado>I cannot reconfigure my system; grub-install fails: /gnu/store/…-grub-efi-2.06/sbin/grub-install: error: efibootmgr failed to register the boot entry: Input/output error. <rekado>above that: ‘Could not prepare Boot variable: No space left on device’ <rekado>the command it ran is: /…grub-efi-2.06/sbin/grub-install --boot-directory //boot --bootloader-id=Guix --efi-directory //boot/efi <bjc>i think it was lilyp who mentioned to me the other day that guix will eat up all the nvram over time as you reconfigure your system. sounds like this is what's happening to you now <bjc>or maybe it was a more general grub problem <gabber>this. nckx told me about that when i ran into the issue. i then changed to grub-efi-removable-bootloader (which fixed the issue) <gabber>i also tried removing unused entries from my NVRAM but that didn't work <rekado>this is all new to me. Since EFI came along I decided to live a life in ignorant bliss. <gabber>it has to do with certain *cough* hardware (IIRC) <rekado>how would I a) determine what entries there are in NVRAM b) determine which are unused, and c) delete them? <podiki[m]>i've heard this too but thankfully haven't experienced it; should be discussion in the irc logs but maybe we need to put this somewhere more formal <rekado>is this something that will keep happening unless I manually go messing with NVRAM entries…? <eyJhb>bjc: Doesn't it just add a single entry to EFI, and then the generations are just added to your boot partition? At least that's how NixOS works w/ EFI <gabber>rekado: it will suddenly disappear if you switch to grub-efi-removable-bootloader (as i did) without doing any manual fiddling <gabber>as for your previous questions: there are tools to inspect your NVRAM and well i had found some entries named "Ubuntu" (which i wasn't aware but probably had installed a long long time ago on that machine, so i deleted it) <efraim>tried to build rust-bootstrap on aarch64 with 4gb of ram and 9gb of swap, I seem to have frozen the machine <efraim>I'll let it continue for now, see if it recovers <gabber>rekado: IIRC the inspection tool i used was `efibootmgr` <gabber>i'm running into "gcry_md_hash_buffer" trying to (re-)build from source.. what did i forget? <gabber>i invoke `./pre-inst-env guix shell --pure -D guix -- make` and have tried both `make clean` and `make clean-go` targets (always the same error) <sepi>So I got as far as to understand that there is no automatic mechanism that can generate search paths for shepherd services from package definitions yet. Is anyone interested in having this working? It seems a common requirement to run interpreted language services. <rekado>I can confirm that using grub-efi-removable-bootloader circumvents the problem <rekado>but efibootmgr shows only a handful of entries, and they all look reasonable <apteryx>hm, setting environment variables in the manifest.scm doesn't seem to be a valid use case anymore <apteryx>they aren't considered by the cached environment, it seems <RavenJoad>Can I use an already-built profile and make/use a guix shell-like environment out of it? This profile is a manual GC root, if that matters. <apteryx>civodul: I've opened #63234, but perhaps it's related to #63230 <apteryx>it's a very recent regression I think <sughosha>Hi all, I installed plasma and plasma-desktop and tried logging in with it, but the screen is stuck at black screen. Is it possible to use anyhow plasma in Guix now? <kaelyn>gabber: I ran into that error recently, and it seemed to go away after I deleted all of the .go files and ran "guix shell --pure -D guix -- ./bootstrap", "guix shell --pure -D guix -- ./configure --localstatedir=/var", then "guix shell --pure -D guix -- make -j$(nproc)". I reran bootstrap and configure in case one of the generated files had a stale path in it (at least that was my thinking last night). <gabber>i was a bit confused because the `clean-go` target is supposed to delete all the .go files (or similar) and it confused me somewhat that make seemed unable to accomplish that... <gabber>also, i'm not 100% sure but `make -j $(nproc)` doesn't work for me when building guix itself -- does this work for you, kaelyn? <kaelyn>Yeah, I've been a bit surprised about that too. Especially when at the end it prints a list of unrecognized .go files that then have to be manually deleted (it seems to me like the clean-go target only deletes the .go files for the .scm files it knows about, though I haven't actually looked into it) <gabber>kaelyn: yes, i think that is what happens with clean-go (a new checkout of the repo doesn't keep track of previously-existing-but-now-deleted-files) <kaelyn>gabber: it has worked for me for quite some time, with both master and core-updates (pre-merge). I did run into an issue in the last day or two where the build would fail when it tried to call git, which I fixed by adding git to the environment: guix shell --pure git -D guix -- make -j$(nproc) <kaelyn>what's the build error you are seeing now? <gabber>it's already scrolled past my terminals line-buffer... but i remember trying that a bunch of times and usually failing. <gabber>i just stopped the single-core compiled and yes, i'm getting a "missing git" kinda error <old>I can't open gnome-tweaks anymore <old>also I don't know why, but gnome-keyrings is now a service, which I've never wished for. Is this new? <gabber>the build works now -- up until HELP2MAN doc/guix-home.1 <gabber>ACTION is wondering whether this is actually a new bug <jgart[m]>old: I got a similar error for evince. See yesterday's mailing list post <Grimpper>Does anyone know if we can use `yarn` in guix? <kaelyn>gabber: what commit are you at for "guix pull" (i.e. reported by "guix describe")? I just did "make clean", reran bootstrap and configure, and rebuilt successfully with the guix source directory at the latest commit (91bfd30ee3) on a system last updated 3 or 4 days ago to guix commit 3676e31. <rekado_>I reconfigured with that removable grub thing and now my laptop wont boot any more. <jgart[m]>Grimpper: You can probably install node and then use npm to install yarn <jgart[m]>Grimpper: Or you can run the nix-service-type and install yarn with the nix package manager <jgart[m]>Grimpper: yarn is not packaged for guix and probably won't be any time soon <jgart[m]>Grimpper: We need a node importer to do that sanely probably <jgart[m]>singpolyma: implemented a node importer for guix in ruby that was used in guixrus to package typescript <rekado_>got to grub with: `FS0:`, then cd EFI/BOOT/, and then run the file there <rekado_>hope i wont have to do this every time i reboot now <singpolyma>enough to make the typing quite some less for me <jackhill>is there a way to contol the compression value passed to gzip for `guix system image --format=docker`? I don't feel like waiting on gzip -9 since I'm going to immediate uncompress it to load it into docker's own storage :) <jgart[m]>jackhill: That sounds like a nice feature add. Is it currently hard coded? I haven't checked or read that code yet <gabber>kaelyn: i'm developing on a new commit which i just rebased onto 91bfd30ee3 <gabber>rekado: whoopsie daisy.. do you have to do that now on every boot or have you been able to resolve it? <jackhill>jgart[m]: I'm just getting into system image too, so I'll keep my eyes out. <jgart[m]>Sounds like something you might be able to make configurable with make-parameter but I'm just speculating since I haven't read what the code is doing there yet <kaelyn>gabber: that sounds like your ./guix/ source tree... what I meant was the commit for the guix channel from "guix describe", also available as the version in "guix --version". Basically I'm asking about the state of the build environment and the package versions that are included in the "guix shell" part of "guix shell --pure -D guix -- make -j$(nproc)". Also, is it possible the commit you are working on is interfering with the build? I jus <kaelyn>t added "V=1" to the make invocation to see what command is run to generate doc/guix-home.1 after seeing the error message in your output, and it appears to depend on the just-built guix (the actual command run is "LANGUAGE= ./pre-inst-env /bin/sh ./build-aux/missing help2man --source=GNU --info-page=guix --output=doc/guix-home.1 'guix home'") <gabber>aha! sorry, i've been able to build it successfully now (i had tried the most recent master commit and when i saw that ci.guix built it successfully i knew i did something wrong) <gabber>and yes, thanks! i've been trying to remember how to get make to be more verbose but wasn't able <sughosha>What does "Failed to guess install tag" mean? <gabber>sughosha: never seen this one before. maybe it's a meson (build system) error? <gabber>i often find myself figuring stuff out reading other (but similar) package definitions <sughosha>I don't know much about meson. This is the first time I am getting this error. <jackhill>for guix system image: is the --network cli swith and the (shared-network? #t) image field supposed to do the same thing? <rekado>gabber: I don’t know. I don’t really want to reboot now :) <rekado>I don’t understand how EFI boot works <gabber>same here. sorry if i gave you the impression that it was easy-peasy with no severe consequences or risks <rekado>one extra complication: in the EFI shell the keyboard layout is qwerty, but my keys have dvorak labels. I can’t remember qwerty key locations, so it’s really quite inconvenient to boot like this. <rekado>kinda shot myself in the foot by selecting dvorak key labels; I don’t need them, but I sure could use a reminder of what qwerty looks like… <gabber>so you went ahead and checked the good ole QWERTY layout on a secondary device via image search? <old>jgart[m]: I just saw the error with evince <old>any quick fix for that? <old>Can't even open PDF now :-/ <rekado>gabber: I opened another laptop just so I could peek at the keyboard while typing on mine <rekado>old: opening gnome-tweaks works for me. Are there other conditions that need to be met to reproduce this? <old>I don't think. I just updated my system on the 30th April and now I can't open PDF with evince nor gnome-tweaks <old>also some UI label are broken in Gimp and firefox <old>(I don't see the X to close the windows for firefox) <old>I've switch generation back to previous one <old>The bug is not there anymore <old>So something in 7a9b3ca63bdea219d3977ed5fdab2ed98eaa36a0..23552fb2fbcb78757e8b563de9466831f6386105 breaks GTK <old>sorry I meant 5b545763ed9b8a3fade7f756d543819fc090953f..23552fb2fbcb78757e8b563de9466831f6386105 <podiki[m]>jonsger: can't reproduce that bug on 854c57c3525325070e261a2e6f81d4016ef44bfa <podiki[m]>but is that on foreign distro? the locales messages suggests so <gabber>or maybe a mismatch between home and system profile <jgart[m]>old: You get the same error with evince? <jgart[m]>Yeah, I'm in the same situation with evince <podiki[m]>yeah, as gabber says we've seen some errors when not every package/profile was updated post core-updates due to glibc updates <lilyp>glibc doesn't like it when you try to run different versions in parallel <jackhill>wait, but how then does guix work on foreign distros or via time-machine? My understanding was that the different versions of glibc didn't see eachother. I wonder what I'm missing with that assumption <lilyp>aiui the problem doesn't really pop up with functionally similar builds, but with differently versioned symbols <lilyp>I'm fairly certain it has to do with the dynamic linker too <apteryx>old: is your system / profile both updated? <apteryx>gabber: you don't actually need to unless you're a committer but it's a good thing to do :-) <apteryx>hm, yes, AI is about to outsmart all of us, friends. It can't even get facts right. <apteryx>I'm curious what exact question you asked it though; bootstrapping probably was in the query <two[m]>linux is made by linus, so guix is made by guiseppe?? <gabber>apteryx: i was mostly confused because git seemed to require that (due to the very top in etc/git/gitconfig) <gabber>i needed to comment the first property to create the commit (without actually setting up GPG) -- something i didn't need to do before <apteryx>that's due to: "Makefile.am: Auto-configure Git on 'make'." introduced with 8b972da068708a8b17f3ab153ea940690ca49ca9 <gabber>ACTION wonders if that very option isn't a bug <gabber>oriansj: creepy AF, but also nice entertainment. also cudos for getting 1/1000th of the bootstrapping thing right (the size of the seed).