<nckx>ss2: Did you stop cow-store and unmount all file systems before rebooting? (It ‘should’ do so for you, sure, but…) <bjc>ss2: and you're currently booted from a recovery usb stick with the old install mounted in /mnt? <ss2>It chickens out saying: chroot: failed to run command "/bin/sh": Exec format error <bjc>there should be old grub.cfg files sitting around in the store from your existing install then. try ‘find /mnt/gnu/store -name grub.cfg’ <ss2>nckx: can't tell at which spot the system crashed. <bjc>might take a bit, but hopefully you'll get one you can work with <bjc>i'd be worried that other stuff has gone wrong, but if you can get it booted you should be able to roll back to a previous system <nckx>ss2: ‘Exec format error’ is different from ‘No such file or directory’. Not that I know what it means here. <ss2>ups, I need to boot with more bits ^^ <bjc>i'm just guessing. it's the only thing that comes to mind that would return that error <nckx>Oh… is gparted live 32-bit? <nckx>That would definitely throw that error 😃 <ss2>no, it can be 64 and what not. Must have needed 32-bit recently.. <apteryx>FATAL: remaining connection slots are reserved for non-replication superuser connections <nckx>Are you on guix-sysadmin@? <nckx>See Mathieu's latest reply, although there's no answer yet. <apteryx>yes, I'll have a look after the evening family routine <nckx>Should I leave it hanging for you or restart cuirass/psql to make it run for another while? <ss2>Okay, I've got a chroot running now. But now I've only got an sh. Nothing else. <bjc>everything else is going to be loaded from a profile <bjc>is there an /etc/profile in the chroot? <nckx>/home/user/.guix-profile/etc/profile <ss2>sure, just sourced it. <bjc>groovy. you should the system installed stuff then <bjc>or what nckx said ;) <nckx>Don't forget to (bind-)mount stuff like /dev, /proc, /sys, … if you haven't yet. <nckx>Tools will go nuts without them. <bjc>if you intend to try to roll back from the chroot, you need the guix daemon started <ss2>But now I've got to inpersonate my user profile to access my pull generations. No/ <ss2>I'd need to have /boot repopulated again. <bjc>the guix daemon does all the actual work of interacting with the store and setting up symlinks etc <ss2>bjc: btw, find /mnt.. -name grub.cfg didn't find anything. <nckx>You should be able to directly invoke ~user/.config/guix/current/bin/guix. <bjc>ss2: oh right, of course it won't. the file is generated so it'd have a hash prepended. sorry. ‘find -name \*grub.cfg’ <nckx>‘find /mnt/gnu/store -name \*grub.cfg’, note the *. <nckx>Or what bjc said I guess that will *probably* work. <bjc>no, you need the path, i think <nckx>(Not if you're in /gnu/store already, but I wasn't serious anyway.) <bjc>really? we move further from god^H^H^Hposix every day <nckx>The . is muscle memory at this point. <nckx>…it works without it but I'll keep wastefully typing it until I die. <nckx>Or use a BSD system I guess? <drakonis>nckx: there is one caveat regarding the drivers, the ones nvidia published only function with turing and beyond <ss2>eh, easy way out: randomly copied grub.cfg from the store to /boot/grub. Booting again. Thx! :) <drakonis>the why? the gpus it supports are actually using specific hardware where all the proprietary juice is <ss2>Could be smarter though to check which one was the most current. <drakonis>and this proprietary juice is not in hardware on the older gpus <bjc>ss2: once you're up, i'd roll back and reconfigure just to be safe <nckx>Now because more proprietary. <nckx>Meh, not a discussion I want to flare up, sorry, ignore me. <bjc>although, thinking about it: one of the things the grub.cfg does is specify which generation you're on (from the gnu.store cmdline option to the kernel). so you should /already/ be rolled back at boot time <nckx>If this were my system I'd run a fsck on it, just to be safe(r). <ss2>I've no idea at which generation I am right now. <bjc>it should check on boot, but it doesn't hurt to do it again <bjc>guix system list-generations <nckx>bjc: Depends on the fs type. <bjc>iirc all the currently supported ones that can be checked are being checked <bjc>looks like the only one that isn't is nfs, for the obvious reason. maybe some of the check-*-file-system procedures are stubs, though <nckx>Not unconditionally, and not—well, I rewrote most of the fsck calling code, it's… complicated. Messy. Yech. I'd always recommend booting with fsck.mode=force after fs weirdness, but it's just me. <ss2>somehow the most current generation is quite broken: https://paste.rs/5dD guix system list-generations throughs an error there. <horizoninnovatio>Good morning! I'm trying to set up evolution with gmail accounts. I've install evolution-data-server and glib-networking & rebooted. The error I'm getting is "TLS support not available". How do I fix this? or is there a better email client that works well with gmail? <ss2>rolling back, then rebooting. <ss2>I can't. I get that same error again. <bjc>the guix pull should be safe <bjc>you may be able to ‘guix gc’ to clean up unreffed generations and get rid of the newer ones as well <ss2>I can't. Even when trying to delete the most current generation fails. Rolling back fails too. Booting an older generation is fine though. <nckx>The only ‘guix gc’ command I would dare run at this point is ‘guix gc --verify=contents,repair’. I see no advantage in deleting things. <ss2>I was just reading that! *nckx -> zzz. Good luck ss2. <ss2>thx, I shouldn't be doing these things late at night too. <nckx>apteryx: I've restarted the service anyway, just to (hopefully) get things moving for now. <bjc>i think these issues wait for late at night to appear <nckx>ss2: They always have a sense of timing don't they? Bed bugs, for sure. Night! <bjc>"bed bugs" i'm going to have to remember that <ss2>Good call though. Gc is found two corrupt items. One is grub.cfg and a raw-initrd file. <ulfvonbelow>I had to 'kill -9' my X server, but now when I try running 'sudo herd start xorg-server' it outputs to /var/log/Xorg.0.log '(EE) Cannot establish any listening sockets - Make sure an X server isn't already running(EE)' <ulfvonbelow>well, strictly speaking, I didn't 'kill -9' my X server, it crashed and died, and I had to 'kill -9' slim after that over ssh <ulfvonbelow>I'd like to resolve this without rebooting if at all possible <ss2>ulfvonbelow: are you sure that you've got no dangling xsession left over? <ulfvonbelow>I'm not sure what that means, and how would I check that? <ss2>look at your process list. Have you got htop available? <ulfvonbelow>ran htop in guix environment, apparently slim is running at 100% cpu usage <ulfvonbelow>and strace isn't reporting any system calls from it whatsoever <ss2>Have you killed it yet? Its childprocesses too? <ulfvonbelow>if htop displays processes as a tree, it had no child processes <ulfvonbelow>yes, I killed it and attempted to start it under strace <ulfvonbelow>but it looks like I need to set some environment variables <bjc>did killing it actually kill it? <bjc>you checked? i'm only asking because drm can make some things not work that used to always work <ulfvonbelow>ps auxww | grep slim reported a new pid that was autostarted by shepherd, so I assume the old one died <bjc>have you tried to ‘herd stop slim’? <ss2>bjc: it isn't looking good actually. Several items are are corrupt. Mostly system-activation, grub.cfgs, no idea how I managed this. Gonna have to start from fresh then. <bjc>ss2: well, at least you have your system config and home config to work from? <ulfvonbelow>(I believe the shepherd service goes by the name 'xorg-server') <bjc>ulfvonbelow: it may not be called slim. try xorg-server? <bjc>ulfvonbelow: if you can't stop xorg-server, and slim keeps restarting i'm not sure what to do <ss2>ulfvonbelow: maybe stop the service first? <ulfvonbelow>it worked to stop xorg-server, I'm currently trying to manually start it under strace <bjc>oh, so slim isn't running anymore? <bjc>ok. that's somewhat sane then <ulfvonbelow>it seems to pass the slim config file name through an environment variable so I need to go hunt down the proper value for that <ulfvonbelow>[pid 9424] bind(8, {sa_family=AF_UNIX, sun_path=@"/tmp/.X11-unix/X0"}, 20) = -1 EADDRINUSE (Address already in use) <ulfvonbelow>lsof: status error on /tmp/.X11-unix/X0: No such file or directory <bjc>oh right, you deleted the file <bjc>huh... this is a situation you find yourself in <bjc>it's really weird that you can delete the file and the x server is still returning eaddrinuse <lechner>Hi, is there a way to speed up guix pull -l ? <ss2>bjc: I did manage to roll back. To a much older generation. Which is good. So I might just clear the generations, do a gc, and reconfigure afterwards? <bjc>yeah, if things are looking ok <ss2>Gonna do it tomorrow instead. Getting much later than expected. :) <bjc>at the very least, your trials today have convinced me that zfs-on-root is still a good goal to work towards. being able to simply roll the whole filesystem back to a previous snapshot would have solved all of your problems almost instantly <ss2>maybe. I'm also suspecting that this mainboard is going a bit crazy unfortunately. It has shown some odd freezes, and now this. <bjc>it does seem like something bad happened when writing to the disk. might want to check your smart stats <bjc>(but zfs protects you from that too) <ss2>Read Error Rate is at a very hight value.. <ulfvonbelow>is there some sort of weird containerization happening with slim or the X server? <ulfvonbelow>that's the only explanation I can think of for why my test program gets ENOENT while the X server gets EADDRINUSE <bjc>ulfvonbelow: not that i know of, no <ss2>the disk is old. The whole thing is old. <bjc>and for random x clients to work, the socket needs to be available in the normal file system, so there'd have to be a bind mount from a hypothetical container to the host to make it available <bjc>as a last resort, you could do something like: for i in ps axugww; do; lsof -p $i; done <bjc>just dump everything and see who's got it open and where <ulfvonbelow>hmm... I think I may have found a bug in our slim-shepherd-service (gnu/services/xorg.scm line 587). Specifically: (false-if-exception (delete-file lockfile)) <ulfvonbelow>this takes place within a gexp that doesn't have a definition for lockfile <ulfvonbelow>the exception raised from evaluating an unbound variable gets suppressed by the false-if-exception though <ulfvonbelow>bjc: I ran: for i in $(sudo ps axo pid); do sudo lsof -p $i; done <ulfvonbelow>I ran sudo /gnu/store/dhxiv0d8n04sa5z6z88ggwnw41fsjh0p-inotify-tools-3.20.11.0/bin/inotifywatch /tmp/.X11-unix/ while starting slim, and it said "No events occurred." <emacsomancer[m]>I'm having trouble updating, 'mutter' seems to get stuck on the 'check' phase. I see some older irc mentions of this issue, but nothing about how to work around it. <mekeor[m]>emacsomancer[mx]: maybe mention the nick here and also clearly define your issue here, e.g. with logs <bjc>ulfvonbelow: i'm out of ideas. you may need to reboot =( <bjc>emacsomancer: i had that issue yesterday. ^C and restart seemed to fix it <bjc>happened two or three times (i was testing things, so did a bunch of reconfigures) <mekeor[m]>quite some guixers live in europe, so maybe don't ask the most difficult question at 3am utc <bjc>seems to be around noon utc things are fairly active, but a lot of people read scroll-back when they get back to their computer, so you can ask any time <bjc>you'll probably want to stick around, though, since it can take hours to get an answer for some things <bjc>there's also the mailing list <Aurora_v_kosmose>> I was at the 5th RISC-V Workshop in 2016, and heard Eric Grosse, then Google's VP of Security and Privacy, say that a future without risc-v was too scary to consider. | Considering the counterproductive attitude of the RISC Foundation, this seems oddly optimistic to me. <bjc>i get that license fees are a problem, but honestly i don't see what the big deal is with the riscv isa. it doesn't seem particularly revolutionary <littlebobeep>Aurora_v_kosmose: The author of that post has claimed there are potential patent infringements with RISC-V but I am not sure which <ulfvonbelow>inotifywatch /tmp *does* report the creating and unlinking of the "/tmp/.X0-lock" file, for whatever it's worth <Aurora_v_kosmose>littlebobeep: Honestly, I'm more concerned by the documentation & NDAs aspect. <bjc>i'm confused as to how riscv can even *have* an nda <Aurora_v_kosmose>Proprietary extensions are basically necessary to make the ISA useful for a number of things. <littlebobeep>Aurora_v_kosmose: Are there actual NDAs for the ISA spec? <bjc>i haven't done a tremendous amount with risc-v, but the published (mostly lettered) extensions seem to cover the standard use cases <oriansj>and the lambda core is good enough to do everything (perhaps not as fast or as energy efficient as extensions may be) <Aurora_v_kosmose>oriansj: That might be a stopper for a project that intends to create Libre (and effective) general computing hardware <littlebobeep>oriansj: Searx returns nothing on risc-v lambda core, what is that? should be a LISP processor lol <oriansj>Aurora_v_kosmose: Depends on how hard core the people are <oriansj>littlebobeep: the lambda core of anything in software/hardware is variables [storages], conditionals [jump if zero], iteration and recursion [call/return] <Aurora_v_kosmose>Using general logic units for GPU work would be horrendously inefficient. <oriansj>Aurora_v_kosmose: we can and we probably have some for FPGAs (if not that would be surprising) <littlebobeep>Aurora_v_kosmose: someone in #fsf claimed they were much less efficient than Von Neumann chips with software LISP interpreters, but when I asked why or how they did not answer <littlebobeep>oriansj: I have not found any HDL code for such designs in my searches <bjc>in terms of extensions, i thought it was explicit that the point of risc-v was to have an open general purpose isa that corporations could build vendor extensions on <Aurora_v_kosmose>littlebobeep: Yeah... I think outside of asking someone who worked with them, few might know. <oriansj>Aurora_v_kosmose: well a framebuffer isn't very complex in terms of hardware and definitely outside the scope of any patents (that haven't already expired) <bjc>risc-v was only ever made to eat arm's lunch, but otherwise preserve the status quo <bjc>google, apple, et al were tired of paying the arm tax. so we got risc-v <oriansj>littlebobeep: tragic, FORTH chips are a dime a dozen <oriansj>also people have made graphics chips that run on the iCE40 FPGAs <oriansj>so might not be able to do 4K streaming video but it appears good enough for a productive computer <the_tubular>builder for `/gnu/store/asi7iylmam00w8hrh7bpxmifcszyylx6-guix-package-cache.drv' failed to produce output path `/gnu/store/n83dqnbagkcg5f7829sq8kc107f03yjk-guix-package-cache' <apteryx>the_tubular: that seems a problem in the current guix <kitty1>ayyy nice to hear the news from nvidia ; wonder what made them do that? small step but a cool one <kitty1>still not nearly enough, hope whoever is responsible keeps up the heat! <Aurora_v_kosmose>littlebobeep: According to folks over in #lispcafe, LispMs have nothing that dooms them to be slower, newer CPU generations just weren't made as fast as the rest of the industry and didn't catch up. <kitty1>what advantages did/do lisp machines have when working with lisp, apart from presumably being more elegant for systems designed around lisp? <kitty1>err or rather would anyone know a good source to read more about that? <Aurora_v_kosmose>Processor-wise, a lot of the type checks & GC operations were directly assisted in hardware. <littlebobeep>kitty1: Did you see they are moving a lot of driver functionality into proprietary firmware, and all user-space code is still proprietary dealing with OpenGL, Vulkan, OPenCL, and CUDA? <littlebobeep>and it does not affect most of the GPUs without this sketchy "GPU System Processor" which allows them to offload a lot of functionality into proprietary firmware (to run on the GSP) <kitty1>littlebobeep: yeah, thats why I very much hope that people hold their feet to a fire instead of *just* celebrating. <kitty1>not really expecting it, but people really need to. <bjc>a lot of them do work, but the functionality is locked behind vendor drivers <bjc>i've seen people make gamer-level nvidia cards work on windows in a vm at the same time as a linux host for relatively mild performance losses, but it required a bunch of driver hacking <bjc>i think amd is similar. the new intel cards are supposed to support it out of the box, from what i've heard <Aurora_v_kosmose>Then so long as Nvidia requires reprogrammable firmware, they're a potential malware risk. <bjc>oh, sorry, brain fart. i'm talking about virtualizing a gpu which has some acronym i can't remember off the top of my head <bjc>iommu works fine these days with most gpus. amd had some issues for a while due to pci reset bugs, but newer cards seem fine, and there's workarounds for older ones <littlebobeep>bjc: apparently Intel Arc GPUs require nonlibre firmware now, which is just when they might've starting to be competetive in any remote way and maybe available as discrete cards <bjc>*if* they support virtualization without hackery and have a decent price point, the intel gpus will have at least a small market <bjc>if your motherboard can split iommu groups in a sane way for you, you're probably going to be fine these days <bjc>oh.. it's just called "vgpu" apparently <littlebobeep>if I can't have a discrete Intel GPU with libre software I do not buy more Intel shit cuz that forces me to use their CPUs <bjc>a discrete gpu should work anywhere there's a pci bus <kitty1>yknow, just a dumb showerthought ; how well would FPGAs handle most GPU tasks assuming the software was also made with it in mind? <kitty1>err, certain notable tasks, rather <littlebobeep>Aurora_v_kosmose: Well obviously the vast majority of GPUs ever made my Intel are locked into the processors because they are different blocks of logic on the same package: iGPUs (very few had horrid PowerVR GPUs but let's forget those), and last I checked the "dedicated" Xe intel GPUs are mobile only so again you cannot use them without being locked on a motherboard with Intel chipsets and CPUs. But <littlebobeep>given what little I have read about it, once a dedicated Intel GPU PCI-e card is made, it will probably require nonlibre firmware to run so it won't work in GNU Guix <apteryx>the_tubular: OK, I've validate that Guix itself is healthy (make as-derivation) <apteryx>I'm now trying to build the same derivation that failed on the CI with 'guix build /gnu/store/kmngv93i710fdpdqhl5rydzh68pxviv3-profile.drv' <apteryx>where does this guix-package-cache come into play <Aurora_v_kosmose>They could make an effort to get with the times and liberate their own firmware. <littlebobeep>note that I am not read up on the details of Intel PCIe GPUs, but if they are "Arc" cores then it won't work in Guix <littlebobeep>Someone online claimed nvidia's GSP.bin firmware is 34 MB hahaha whoops <apteryx>sorry, no dice and it's late. I was trynig to figure out how to run the 'package-cache-file' procedure on the current checkout guix as a way to automatically bisect, but I'll need more time/energy. Hopefully someone else can fix it before me :-) <apteryx>the_tubular: it's the profile hook used when building guix itself (not clear on *when* it's invoked by the CI exactly still) <apteryx>but the purpose is to produce a cache file of all the current guix packages <apteryx>and it fails on some unbound gexp related variable, so something at the level of packages definition most likely <apteryx>we just need to figure out how to build just that derivation for a given guix revision, then run git bisect on it to find out the culprit <the_tubular>So a simple package definition can cause guix to stop being able to update anything ? <apteryx>yes. luckily most problems are caught at compilation time... so it'll be interesting to know how this one slipped in. <emacsomancer[m]>where are the gdm configuration/cache files located? was trying out sddm and I can't get gdm to work afterward (even reverting to an older derivation) - I assume some configuration file for gdm got altered when running sddm <civodul>bjc: just saw your comment about gdm on the fediverse <civodul>looks like we have some debugging to do :-) <maximed>horizoninnovation: What does "echo $SSL_CERT_FILE, $SSL_CERT_DIR" say? <maximed>For TLS things, you usually have to install a certificate root. <maximed>Usually that means installing "nss-certs" (= Mozilla's certificate root) <maximed>In principle you could use another root, but no other roots are currently packaged in Guix. <PurpleSym>Is there any way to actually get the latest successful build? <PurpleSym>Without `/archive` it correctly redirects to the last successful build. <civodul>PurpleSym: weird; do you know when it started failing? <PurpleSym>No idea, civodul. But the CI is literally on fire right now. <civodul>that said, you could run "guix time-machine -- pack guix -C xz --localstatedir --profile-name=current-guix" <civodul>that'll give you the same Guix tarball <civodul>or maybe you install a fresh Guix as part of your CI process and you want the latest one? <PurpleSym>Yes, it’s a fresh Guix install with the latest tarball, so I don’t have to run a slow `guix pull`. <jpoiret>has the package cache issue been fixed? <civodul>i took a look at the Cuirass logs and all on berlin and can't figure out what's wrong with those evaluations <civodul>what's super weird is that things do get built <jpoiret>i was git grepping for gexp, seems like there are two (guix gexp) use-modules in commencement.scm :p <phodina[m]>does somebody know how to correctly build linux kernel module in Guix? I ran into some issues here <PotentialUser-42>Hello. I am getting a hash mismatch when building my own package. What might be the difference to checkout hash during guix package -i and guix hash -rx . inside my local dir? ***zeta is now known as zeta_
<davidl>PotentialUser-42: does your packages bundle one or more git submodules? Do you specify a git commit in your source or a filepath? <bjc>do a quick check on /var/lib/gdm and make sure it has the right ownership <bjc>civodul: i just saw your response, thanks! i'll try to debug it further once i get some time later today <zeta_>Hello. I can't install GNU Guix System because I can't connect to Guix's servers. Are Guix's developers blocked it for russian users? And can I install this distribution without internet connection? Thank you <bjc>zeta_: the substitutes servers (where the binaries are downloaded from) have been having intermittent issues the last few days, so it may not be that you're from russia <PotentialUser-42>davidl I specify a commit and version - no submodules though - but I use an access token in the git-reference https url <bjc>an yes, you can install it without internet, but it's more complex than what you're likely doing now <PotentialUser-42>davidl If I just replace the actual with the expected hash it works, but that does not sound right. guix hash -rx . should give me the right hash. I do something wrong <bjc>sorry - i misspeak - you can install it without access to the substitutes servers, but you'll still need internet to get the source files for packages <davidl>PotentialUser-42: just note that guix hash -rx works on current files not whatever files are in the commit. If you have a .gitignore file for example that might create a difference. <zeta_>bjc: ok, thank you for help. I'll try install this on holidays <zeta_>bjs: but it's seems strange when I can't connect to guix.gnu.org without VPN <bjc>ah. it may be that russian ips are being blocked after all, then. i think i heard something about gnu services doing that because of ddos attacks or something. but that was a month or two ago <zeta_>bjs: thank you for this information. I'll try do something <littlebobeep>bjc: we actually had a discussion in this channel about offline installation with local source building everything and it seems the tooling is not 100% there unfortunately <Tirifto>Hello! I notice that the ‘glibc-utf8-locales’ is now gone, and the manual advises defining a custom locales package instead, even telling me what the definition should look like. I think that’s awesome, but how exactly should I make use of that definition? The first example of packaging in the cookbook suggests putting the definition in an arbitrary file and asking Guix to read that (guix package --install-from-file=my-hello.scm <Tirifto>); would that be a good idea for a custom locales package? ***f1reflyylmao is now known as f1refly
<fvio[m]>hey everyone! I'm currently trying to install guix from a sytemrescuecd live usb. Is there a way I can install guix from here? <fvio[m]>i've so far installed the package manager, but can't figure out what to do with the cow-store service <allana>Hi #guix! Anyone here use libvirt-service-type? I am using it for the first time and wondering how people interact with it. For example, I installed the virt-manager GUI application and it seems to want to talk to the wrong socket "/var/run/libvirt/virtlogd-sock" instead of the existing "/var/run/libvirt/libvert-sock" <maximed>Tirifto: Maybe install "glibc-locales" instead. <maximed>If you want a custom locale package, I think using manifests ("guix package -m") instead of "guix install" would be more practical <maximed>otherwise you'll get the problem that "guix package -u" doesn't know about your custome locale package <maximed>horizoninnovatio: I don't think Guix uses os-prober. <Tirifto>maximed: Thank you; I’ll see if manifests are workable for me, since I’d prefer to spare some space. *allana figured it out, selected a "QEMU/KVM user session" option :-) <civodul>zamfofex: hi! you're right to ask, no problem <civodul>in theory there are 40 people who could review and push the changes <civodul>in practice though, that's a much narrower set of people <civodul>anyway, i'm walking up the patch list and i'll get to this one real soon i guess <civodul>sorry for the delay, i know it's frustrating! <mekeor[m]>would it be possible to run guix in a container on mac os, to install packages which would be used on mac os natively, i.e. without containers? <maximed>mekeor: Guix currently does not support that OS. <zamfofex>civodul: Thank you for getting back, I really appreciate it! I know people are oftentimes busy and I don’t want to sound demanding, is all. Other than that, I’ve just been a bit eager to try to get networking functional for the Hurd again! (Which depends on that patch.) <zamfofex>I don’t know whether such a tarball work on Mac OS, though. <civodul>zamfofex: oh! networking on the Hurd does work on master though, right? <civodul>i have a childhurd i can talk to at least :-) <zamfofex>civodul: I mean on real hardware! Apparently the builtin Mach drivers are not sufficient in my hardware, even though they work fine on QEMU. <civodul>zamfofex: oh my bad, that one slipped through as well <civodul>cbaines: you have great debugging & programming skills though :-) <zamfofex>civodul: No, it’s fine! As I said, it doesn’t quite work yet. I was planning to post an update once I figured out whether my assumption is correctafter the glibc patch. <cbaines>civodul, I have had a look, but I think addressing it would require somehow changing the inetd stuff to support listening on multiple sockets, one for IPv4 and another IPv6 one <civodul>cbaines: ok; could you share your findings in the issue, including perhaps a preliminary patch? <horizoninnovatio><maximed> "horizoninnovations: I don't..." <- I've installed os-prober so assumed it was used! Anyhow, is there a way to automatically update grub.cfg with other linuxes partitions? <apteryx>civodul: I feared the Btrfs array may have filled up, but no, it still has about 2.5 TiB to go <civodul>apteryx: yes, sounds good; so these are the new SSDs? <horizoninnovatio>Evolution email client error: Could not connect: Network is unreachable - any solution please (this is driving me nutts! <cehteh>you have network on the machine at all? <cehteh>dunno about evolution, but could be firewall in that case <rekado_>apteryx, civodul we also have 100TB on the SAN that I think we should start using. <apteryx>rekado_: agreed, and I'd like to continue my btrfs boot experiments on node 129 <apteryx>I'll have a similar 5 RAID10 array soon to test at home too <apteryx>rekado_: question about the new SAN; there are many drives exposed to the OS; but we can use a single one of them in the config correct? <apteryx>(why is it exposed as multiple drives?) <apteryx>civodul: the SSDs are currently hosting mostly /var and /home, which include the Cuirass database and cached NARs <civodul>and yes, using the 100 TB sounds like a good idea :-) <civodul>apteryx: is there a problem specifically due to booting on btrfs? <apteryx>I've not seen it outside of the build farm setup, but there is one there yes <apteryx>our initrd lacks udev support, and btrfs relies on it to wait for the drives to be online before assembling the array, so it's probably down to this <apteryx>I haven't see the issue in our new Btrfs RAID10 system test <civodul>our initrd has code to wait for devices, similar to udev; could it be that it's missing something for these devices in particular? <civodul>(normally the checks that "guix system reconfigure" makes would catch this, but who knows) <apteryx>civodul: where is this synchronization code waiting for devices readiness? <apteryx>this probably does it for regular file systems that simply appear under '/dev/sdxN', but Btrfs is special in that it uses its own means to detect the file system arrangement ('btrfs device scan') <apteryx>I suspect that if 'btrfs device scan' runs before the devices are ready it will cause the array to be degraded (missing drives) <apteryx>the Btrfs udev rules meant to be used in the initrd are define in: /gnu/store/8c136063irrx9hig6dmf1xqli6rgibkk-btrfs-progs-5.15.1/lib/udev/rules.d/64-btrfs-dm.rules <PotentialUser-42>Hi. I created my own python package. I can install it via guix package -i and afterwards start a python3 interpreter and import it. If I create a docker image with that package I can see it in the store but I can not import it. How can I tell python to look at the right place? <apteryx>you need to include python in your image; this will cause the GUIX_PYTHONPATH environment variable to be defined and your package should be importable <apteryx>rekado_: I saw a new public IP being registered in berlin; I guess what remains to be done is to assign it to some (non-berlin) machine to provide access to iDRAC when berlin is down? <PotentialUser-42>apteryx This is my build command: guix pack -f docker -S /bin=bin python-ammosreader bash coreutils python grep ffmpeg findutils which <apteryx>ah and yes, you'll have to source teh profile <apteryx>so expose /etc to, and connect via 'bash -l' or something or manually 'source /etc/profile' <rekado_>apteryx: we have two public IPs. .40 and .41. We haven’t assigned .41 to anything yet. <rekado_>the other IP on berlin is a private IP on the management network, allowing you to access the iDRAC of all nodes. <rekado_>we’d have to assign one like that to whichever node will get the second public IP. <rekado_>apteryx: re SAN: there are four devices, because the SAN exports four paths to the SAN slice. Ideally we would be using multipathd to benefit from this redundant connection. <apteryx>rekado_: would it be possible to assign the .41 to one of the running build nodes already? <apteryx>and thanks for explaining the SAN thing <apteryx>PotentialUser-42: not sure which page you are talking about, but consider reporting it to them <apteryx>OK. The Guix project has no control over such site, so the best we can do is report it to its author :-) <rekado_>apteryx: yes, we could assign .41 to one of the other nodes. I just need to know which so I can arrange for that node to be hooked up to the public switch. <apteryx>is there another build node (apart for the currently foobar'd 129) which is newer or otherwise deemed more reliable than others? we should use that one <rekado_>when I’m in the data centre again I’ll hook one of them up <apteryx>OK, neat! I'm looking forward to be autonomous in sorting out the mess I sometimes create ;-) <rekado_>speaking of mess: have you been able to network-boot node 129? <rekado_>we use cobbler here, and I have no idea how it works <apteryx>I think I was stumped on something basic last time I tried, but I forgot what... let me try again. <apteryx>civodul: re current CI failures, so we do not know why building the package cache fails? <apteryx>I can reproduce the failure by 'guix build /gnu/store/kmngv93i710fdpdqhl5rydzh68pxviv3-profile.drv' locally <apteryx>I wanted to run git bisect with an invocation of guile attempting to build the package cache for the current guix checkout, but I'm not sure how to do that <civodul>apteryx: where do you see that building the package cache fails? <civodul>apparently there was a typo in a commit yesterday that led to that <apteryx>I wonder how we could catch this problem before it reaches the main branch <civodul>apteryx: that's commit b33ebc22fb, fixed right after that <apteryx>OK, I see the latest commit built fine <civodul>"make" should have reported it as an unbound variable already <apteryx>uh. so the commit was made without the pre-push-hook <apteryx>or is that just a warning that doesn't fail the build? <apteryx>rekado_: so, how I was expecting to be able to try a PXE boot was: 1. connect to serial of node 129; 2. go to the iDRAC page of node 129 and request a reboot; 3. at the serial, see the boot options and choose to PXE boot from some IP address <apteryx>yeah, can't seem to enter F11 (Boot Manager) or F12 (PXE Boot). It always end up on the GRUB screen. <apteryx>I think the reason node 129 isn't bootable is because I had forgotten to clear the inherited swap device field <apteryx>a rescue boot GRUB menu that boots our install image would be handy <rekado_>does PXE boot fail early and then it moves on to the local disks? Or does it boot from disk directly? <rekado_>if it’s the latter then you should be able to change the boot order in iDRAC. <apteryx>I tried pressing F12 to select it (or F8 to enter the Boot Manager) at boot without effect <rekado_>if it’s the former then it’s likely my incompetence with cobbler or some network setting that prevents our nodes from seeing the cobbler server. <apteryx>good idea to set only one boot device to PXE in iDRAC and retry <rekado_>I don’t want to waste your time. I really hope I accidentally got everything right when setting up the Guix image on cobbler. <rekado_>lots of hoops to jump through; quite disorienting. <apteryx>I don't feel like I'm wasting my time, no worries :-) <apteryx>next time you visit the datacenter, if you could leave a Guix install USB device plugged in, that would probably be useful <apteryx>I've now enabled only PXE in the boot devices (after entering setup with F2) <rekado_>the Guix entry is mine; the others were configured by my colleague. <apteryx>although now it seems stuck Loading initial ramdisk ( /images/Guix_System_1.3.0/initrd.cpio.gz ) ... for rather long <rekado_>this reminds me of the early iPXE days when I tried to install the build farm nodes over PXE <rekado_>let me see the cobbler settings for that record again; maybe I did something stupid <rekado_>it’s actually supposed to load /var/www/cobbler/distro_mirror/Guix_System_1.3.0/gnu/store/6gqlkmklgvqks6nqf6bc39vj044pjvjd-raw-initrd/initrd.cpio.gz <rekado_>but in any case: /images/Guix_System_1.3.0/initrd.cpio.gz also exists (under the cobbler prefix) <rekado_>I just feel that Guix System is a bad fit for the assumptions cobbler makes about distros <rekado_>I would expect all the locations to be wrong, because /gnu doesn’t actually exist, nor does the partition that our image expects to appear. <rekado_>I see this in the logs: Client ::ffff:141.80.167.186 finished /images/Guix_System_1.3.0/initrd.cpio.gz <rekado_>so it looks like kernel and initrd have been served to the machine <yarl>make cscope does not work? <apteryx>rekado_: same result with ubuntu. perhaps serial related <rekado_>the rocky live stuff should work, tohugh <bjc>emacsomancer: it should be owned by ‘gdm:gdm’ <emacsomancer[m]>bjc: hmm. I wonder why it got changed. installing sddm? or unrelated? <bjc>there's a bug somewhere in either the user management or the gdm activation code <bjc>but if you remove the gdm service, then add it back later, this happens <emacsomancer[m]>right now I get "chown: invalid user: ‘gdm’" - probably have to reinstall gdm first? <pashencija[m]>I'm generating an image, so both correct FS type and boot flag are important to me <maximed>horizoninnovatio: not that I know of, but for manual configuration, have a look at "info '(guix)Bootloader Configuration'" <maximed>In particular, the "The Other Distro" example <maximed>It's not something I've previously done myself. <maximed>paschencija[m]: IRC doesn't support multi-line messages. <maximed>The full message wasn't directly available to people on IRC <maximed>Also, how is it used in the script?? <apteryx>rekado_: the wip-pyyaml branch can be deleted, correct? <maximed>Would anyone like the WIP antioxidant code to be available in a channel? <maximed>So people can do "guix install antioxidated-hexyl" and such. <maximed>And maybe built by ci.guix.gnu.org for substitutes and a red/green / FTB/builds dashboard. <apteryx>maximed: perhaps as a wip-* branch? I don't see how using it as a channel would be more convenient; what is this antioxidated-hexyl package? <maximed>It's currently developed outside Guix itself <maximed>It's also not just a build system, it also needs to rewrite package definitions a bit <apteryx>ah, I had forgotten the goal is to have it as a standalone tool <apteryx>oh. How does it rewrite package definitions, and for what purpose? <maximed>basically, (define-public antioxidated-hexyl (vitaminate/auto hexyl)), where 'hexyl' is a rust app and 'vitaminate/auto' is the package definition rewriting procedure <maximed>Purposes: (1) break package cycles (often caused by test dependencies, sometimes by optional features) <maximed>(2) Set the required ‘features’ for each package (basically Cargo's equivalent of ./configure --enable-foobars) <maximed>(3) resolve version conflicts -- usually by picking the newest version. <apteryx>it seems like 2 could be handled at run time in the build system perhaps; I'm curious about the other 2 <ulfvonbelow>is there a way to tell 'guix pull' to only authenticate some channels? For example, if I have a channels.scm with a channel from a remote host and a local customized guix I'm working on personally, I'd like to be able to pull without having to commit and sign everything I'm currently working on. <ulfvonbelow>alternatively, is there a way to use multiple channels from pre-inst-env? <maximed>(4) fix build failures caused by using different versions from what Cargo does (see, e.g., "rust-x509-parser"'s #:phases in guix.scm) <maximed>(4) can probably avoided but the packages will need to be updated anyway <maximed>(2) is mostly done by the build system. <maximed>antioxidant-build-system enables all the "default" features by default. Or if there are no default features, all the features. <maximed>However, you can have situations where "rust-foo" requires the "baz" feature of "rust-bar", but "baz" is not a default feature. <maximed>So it needs to be added manually. That's one of the things that vitaminate/auto does (there's a mapping of package names -> extra features somehere) <maximed>cargo-build-system avoids (2) by compiling "rust-bar" with the required feature again when building "rust-foo". <maximed>But that's rather costly, so the idea is to avoid that in antioxidant-build-system. <maximed>apteryx: By making it a channel instead of a branch (for now), you can still use 'master'. <maximed>It's also a bit easier to develop it as a channel, no need for ./pre-inst-env, make, make clean, ./configure or "guix shell -D guix" <apteryx>it seems like we'd probably want to move to use this antioxidant-build-system for most packages, so it'd be nice if the extra rewritting procedure boilerplate could be avoid to keep things simple <maximed>The idea is to move the rewriting code into "guix style" <apteryx>OK, nice! Do we already apply guix style when importing packages? <maximed>$ ./pre-inst-env guix style -S antioxidate --> all rust packages now use antioxidate <maximed>apteryx: I don't think so, though the contributing guidelines ask somewhere to run "guix style" <maximed>I suppose "guix import crate" could be modified to emit 'antioxidate-build-system' packages? <apteryx>OK, thanks for explaining the rationale for the channel, it makes sense <apteryx>yes, or we could take care to make every importer use guix style to format by default <maximed>Also, with a channel, I could just push the changes without having commit access to Guix itself :p <maximed>I don't know if Cuirass does containerisation though <apteryx>we can fix the commit access bit, if you like! <apteryx>rekado_: also stuck on Loading initial ramdisk ( /images/Rocky-8.5-x86_64/initrd.img ) ... <emacsomancer[m]><bjc> "yeah" <- bjc: thanks! (recursively) changing the ownership of /var/lib/gdm fixed it (after a reboot). <lechner>Hi, what's the right way to fix unknown or invalid certificate issues, please? Installing nss-certs does not help. <bjc>emacsomancer: glad to hear it <apteryx>lechner: it depends. if you are using openssl based applications, install openssl along nss-certs <apteryx>if you are using gnutls-based applications, you need to ensure the certs are availabel under /etc/ssl/certs <rekado_>apteryx: wip-pyyaml can be deleted, yes <rekado_>apteryx: did you try the “Rocky LIVE” entry? <rekado_>(my colleague wrote a cryptic “try now”, so I’m guessing something was borked.) <apteryx>it gets stuck the same, at least from my serial console <apteryx>raghavgururajan: the wip-gnome3.34 and wip-gnome3.36 branches can be deleted, correct? <apteryx>rekado_: Rocky-8-x86_64-LIVE or Rocky-8-x86_64-LIVE-GuixFarm ? <apteryx>I get the same result with Rocky-8-x86_64-LIVE-GuixFarm <mekeor[m]>lechner: are you on guix system? if so, did you add nss-certs to your system package list? <apteryx>rekado_: oh, the 'Rocky-8-x86_64-LIVE' one boots! <apteryx>what's the setup difference? perhaps it can be applied to our Guix image menu <mekeor[m]>is cubes os any more poweful than a guix system where you launch programs in guix-shells? also, is it possible to e.g. start chromium inside a guix-shell while giving it read+write access to a browser profile? <lechner>mekeor[m]: now 'reconfigure' fails with a git error on savannah, but i can get substitutes <apteryx>rekado_: it booted but I can't login ^^' <mekeor[m]><ulfvonbelow> "is there a way to tell 'guix..." <- you can maybe just use guix package -f file.scm? <mekeor[m]><yarl> "make cscope does not work?" <- whats the context? <ulfvonbelow>mekeor[m]: trouble is I want to reconfigure my system using code from my guix checkout as well as remote channels <ulfvonbelow>oh, also, anyone know why whenever I reconfigure, the permissions on /var/run/dovecot and /var/run/knot get messed up? /var/run/dovecot ends up owned by knot:knot and /var/run/knot ends up owned by root:root <pashencija[m]><mekeor[m]> "> <@pashencija:matrix.org> There..." <- Of course it does! <pashencija[m]>So it works fine with gexp unless I copy and rename function <mekeor[m]>> <@pashencija:matrix.org> Of course it does! <mekeor[m]>> It's `(initializer (gexp initialize-efi-partition))` <mekeor[m]>maybe paste both files completely in a pastebin <mekeor[m]>i'm not sure how your messages are displayed on irc. please use pastebins instead <pashencija[m]>I have also tried both (partition-table-type 'mbr) and (partition-table-type 'gpt) <pashencija[m]>I have tested the system run on Raspberry. It's up to the image now. <pashencija[m]> * I have tested that the system runs on Raspberry. It's up to the image now. <lechner>Hi, my issue is fixed now, but should nss-certs perhaps be a prerequisite for Guix system?