IRC channel logs
2023-11-26.log
back to list of logs
<isguixcidown>hi everyone, username basically. `substitute: updating substitutes from 'https://ci.guix.gnu.org'...` is taking an extremely long time -- is cuirass down for maintenance or is it just facing high load ? <isguixcidown>hmm just got 504 gateway timeout trying to go to it directly in browser <Kolev>How do I give a Guix System container full network access? <lechner>pull says download from ci.g.g.o failed for module-import <lechner>sneek / later ask mirai / would you mind if I change %certbot-deploy-hook back to %nginx-deploy hook in fec8e513803970f5105817ae80b696605bbf3b03 ? certbot accepts multiple --deploy-hook options. I have a patch to make 'deploy-hooks' a list and in that case, the names can be service specific.thanks! <tjout>How do I use a keyfile for LUKS drives on startup? I read about mapped-device but afaik I would still have to enter a passphrase. <tjout>My setup consists of a BTRFS raid array made up of five encrypted drives. On the previous distribution I had crypttab handle this for me. <Andronikos>issues.guix.gnu.org and ci.guix.gnu.org are not working. <ieugen>PING issues.guix.gnu.org (141.80.181.40) 56(84) bytes of data. <ieugen>64 bytes from 141.80.181.40 (141.80.181.40): icmp_seq=1 ttl=53 time=53.2 ms <Andronikos>ieugen: For me as well. Substitutes from ci are down as well. <ieugen>I am also seeing substitutes issue - time out <Andronikos>ieugen: I doubt it. Those incidents are kinda normal and happens every once in a while. <ieugen>maybe a hosting provider issue or network maintenance on the ISP side ?! <tjout>Substitute servers are down for me too (Germany, Vodafone) <Ironsmith>hello guix! i have a newbie question: i just wanted to confirm, there is no way to add a service (such as `sddm` from `guix system search sddm`) directly via the guix command (similar to `guix install`), is that correct?the only supported way of doing this is editing the configuration file and <Ironsmith>running `guix service reconfigure file.scm`, is that ri <tjout>Seems like all of gnu.org is down <cbaines>I guess that's a coincidence as I think issues.guix.gnu.org is separate from GNU infrastructure <evilsetg>I have an old guix on foreign installation and when trying to `guix pull` it is trying to get substitutes from guix.example.org. Does anyone know how that could be? <evilsetg>Maybe I tried some tutorial to add substitutes but there is no guix.example.com in my channels.scm. <ss2>Is it timing out? It looks like some servers are not available at the moment. Can't pull either. <evilsetg>Yes, it's timing out. Maybe that's it then. <ss2>Substitutes aren't available either. <nutcase>The good news in "guix issues is down" is that there are no issues anymore <civodul>hmm berlin.guix.gnu.org does not respond <ss2>Hello civodul, was about to tell you that. <evilsetg>I am tinkering a bit with the guix boot process. Trying to fit the installation image into an initrd. While doing this it seems I run into a problem. The system-boot procedure seems to expect that the new root file system is to be mounted. I want to use the rootfs itself though and no changeroot since this is intended for a kexec and I can only pass the initrd. This is probably not possible as the `boot-system` code is now. The only solution I could think <evilsetg>of that does not involve changing the `boot-system` code is to create a new filesystem on top of rootfs and switch-root to that. <yarl>Are the substitutes servers alive? <nckx>evilsetg: I ran Guix System in an initrd for a while and didn't find a solution that didn't involve patching that part of the boot code. Your solution never occurred to me. <nckx>Shall I hard-reset berlin? <nckx>Nothing implies MDC-level failure to me… <nckx>I'll do so in 12 minutes. <PurpleSym>I can’t build guix from a git checkout right now: “@menu reference to nonexistent node” in various locations. Any fix? <lechner>PurpleSym / what's the last time you ran 'make clean'? <PurpleSym>Just now. I also tried `make distclean` and `git clean …`. <nckx>PurpleSym: This usually means you're not using Guix's ‘recent’ & patched po4a. The one provided by ‘guix shell -D guix’, for example. <nckx>I've reset berlin but nginx failed to start… <nckx>PurpleSym: I think that's somewhere near the cut-off, certainly worth trying a pull first. <lechner>nckx / can nginx find the certificates? <nckx>Not the issue, this is something to do with the anonip services on berlin. <nckx>nckx@berlin ~$ sudo rm -r /var/run/anonip/* <nckx>nckx@berlin ~$ sudo herd restart nginx <nckx>Service nginx has been started. <nckx>It was a steel-toed reboot as I couldn't SSH in. <civodul>/var/log/messages suggests something bad about btrfs <civodul>is the hard-reboot procedure documented in maintenance.git? <cow_2001>Guest32: just some server down then back up again <PurpleSym>nckx: Nope, the reference error persists, even after `guix pull && make clean`-ing. <Guest32>civodul hmm, I added myself to that group, but when I try to access my keyboard with chromium. I get the message nnection.c612f1cc.js:3 Uncaught (in promise) DOMException: Failed to execute 'open' on 'SerialPort': Failed to open serial port. Do you have any idea, what I am doing wrong here ? <civodul>Guest32: you may need to log out and re-log in; run the ‘id’ command to make sure changes are in effect <Guest32>civodul what is the id command exactly ? <nckx>Part of coreutils, you should have it by default. <nckx>civodul: [btrfs] Oh dear. [maintenance] Not sure, I did it from memory, but I can add it if you want it public. <Guest32>nckx how do I execute that command ? <nckx>…type ‘id’? I'm not sure which context you're in. <nckx>Membership, like environment variables, doesn't take instant effect globally, you can be in different groups in different contexts on the same system. Hence the generic advice to ‘log out & back in’ for both. <Guest32>nckx okay, my group dialout is missing there <nckx>If you're listed as a member in /etc/group, log out & back in :) Otherwise, your (re)configuration did not take effect. <Guest32>nckx okay, I will log out and log into guix again <Guest32>then I will check the id command again <nckx>It's a thumbs up emojo but I guess you don't have the font. <nckx>.5 GiB of tofuless goodness. <nckx>lechner: Is there another one-step ‘install this to get emojoed' font *besides* font-google-noto in Guix, that you know of? <lucypoo>hey there, i am creating a package that requires libgl.so and mesa provides this, on other systems, different hardware driver packages provide different libgl implementations, is this the case on guix. and if so then how do they get picked between when one installs a package which requires libgl. Would such a structure not break reproducability? <lucypoo>this one goes out to my fellow guixers compiling qtbase <lechner>nckx / i'm not even sure that's enough <nckx>lucypoo: It breaks a very strict definition of run-time reproducibility, but there are many things that Guix doesn't lock down for its build outputs once they run free on real systems, such as the kernel, environment variables (even wrapped binaries tend to append, not replace, those), etc. <nckx>Then there's the fact that ‘hardware driver packages’ exist, AFAIK, outside of Guix's free-software worldview? <nckx>(They don't need to, but in practice Mesa provides everything we care about, no?) <Guest35>nckx thanks, now it works, you are the best, thank you so much <nckx>lechner: Do you mean that -emoji isn't enough? (I need the full noto package for other things, so I've never tried the -emoji variant on its own.) <nckx>Guest35: civodul was first! But you're welcome. <lechner>nckx / it's enough foe what you type but somehow not for my Emacs modeline <lucypoo>nckx: ah ok, thank you very much, so the only provider of libgl on guix should be mesa then? <nckx>It's the only one that I'm aware of. <lechner>i only spent half a year not getting your jokes and Zzzz's! <nckx>libglvnd was added to Guix a while back, which always seemed like a wink-wink-nudge-nudge package to include in an FSDG distro, so check if your software uses that. <lilyp>vivien wait I'll push the fix <xelynega>Is there any documentation on how the ld-wrapper chooses which path to replace. <xelynega>For context I'm trying to get `nslcd` authentication to work for tty and sshd, and `strace` shows that libnss_ldap.so.2 is failing to load for `su` and `sshd` since the only load path attempted is the glibc store path(more details https://www.reddit.com/r/GUIX/s/4ng7qs0fZM). <xelynega>From what ive read, at build time the app should be creating an ld.so.cache to point the app towards the stores that it needs to load each library from, but what information in the package instructs the LD wrapper to make this association? <lechner>Hi, can anyone think of a reason why 'wrap-program' would need to prepend paths instead of setting their absolute value, other than being cautious? <nckx>Arbitrary example: many programmes have configuration options that support invoking user-defined commands from PATH. <lechner>i am not sure PATH should ever be wrapped <nckx>PATH is very frequently wrapped. <nckx>While bash matches the description, I really meant non-shells that might support some foobar.unlockcmd = gpg --foo option. <nckx>Where gpg is but one of many options that the packager can't or shouldn't predict. <lilyp>oh, but prefix-wrapping gpg would be bad in this instance, so you'd have to suffix-wrap <lechner>is wrapping PATH a sign of a tired packager? <nckx>But since this risks moving towards a ‘convince me why I shouldn't reset $VAR while I poke holes in each example’ discussion: resetting (rather than prefixing or suffixing) is the unexpected behaviour that needs a good rationale, since it most changes the behaviour of the original unwrapped binary. <lilyp>there are legitimate reasons to do so, but in most cases yes <nckx>I always recommend patching but sometimes it's just not reasonable, laziness aside. <nckx>Yeah, not sure why I read it as lazy. <nckx>Still, fatigue-induced laziness is not an insult in my book. <lechner>i really did not mean to offend. i rewrote wrap-program to use Guile <nckx>I don't think anyone was offended. <podiki>lucypoo: there was a discussion on guix-devel recently and actually libglvnd is the one that provided the needed libgl in that case (the mesa one doesn't have the same symbols) <nckx>lechner: You? No. Me? Probably. <lucypoo>podiki: thanks, i just tried the package i am making: python-vispy with libglvnd but it did not immediately work whilst it did with mesa, i have not explored further however <podiki>I don't know if we use libglvnd much, and mesa I don't think is built with libglvnd as it would be in most other distros <Guest35>does anyone know, why print scren in flameshot is not working out of the box in i3? <podiki>we could build it with the libglvnd option but not sure that would do anything in guix without figuring out how to support other gl providers <nckx>lilyp: In my imaginary example, gpg would not be an input at all, just a reason that the original PATH should be preserved at all. <lilyp>but if you somehow want to provide a "baseline" gpg, you'd have to suffix path <lechner>nckx / lilyp / okay, thanks! is there a reason wrap-program ever needs to amend an existing wrapper? i implemented it but was surprised to see it. <nckx>Double-wrapping isn't common, but it's more common than you might think (..foo-real-real). I think the best argument is that build systems should wrap by default when it's the most user-friendly thing to do, but also that users of a build system should not have to know about this, especially if it ever changes. <nckx>And avoiding ..foo-real-real by having your implementation detect and prevent it is good? <efraim>podiki: I don't think armhf has moved much in the past 18 hours, I vote merge <podiki>efraim: you read my mind, I was just looking at the QA page <efraim>aarch64 on Bordeaux is almost higher than x86_64 on Berlin <podiki>is it customary to do a final merge of master into branch just before merging branch into master? <podiki>efraim: I saw that! i guess that's a good sign if I want a SBC on aarch64 :) <efraim>Only if there's something largish has been updated since the last merge, but it's generally not a bad idea. When was the last master->mesa merge? <nckx>lechner: No, but it used to (if not in Guix then certainly in Nix!). I thought that was precisely what you were asking: why the wrapping procedure would ever need to amend an existing wrapper → because it is sometimes called twice on the same target. <nckx>Depends. Was it me? Then yes. <nckx>Yes, and I thought you were asking why it would ever need to do so. <podiki>efraim: about 5 days ago, I count around 140 commits to master since then. I might as well. figure today will be quieter on guix front, let it build new leaf updates and then I'll merge mesa-updates in this evening <lilyp>double-wrapping used to be the default in glib-or-gtk-build-system <podiki>efraim: thanks for your help on the other architectures and giving it some love! <efraim>Sounds good. Working on the odd hardware is my fun project <isguixcidown>hey guix, seems that substitute servers have been down for ~10hrs, anyone kniw what's up? <nckx>lechner: Whether the mosh author was tired isn't easy to answer as you seem to think. Maybe they were fully caffeinated but patching would require a ‘clever’ regexp that they thought too ugly to maintain. Maybe patching ‘my $client = 'mosh-client';’ would suffice, but this could still objectively change user-observable behaviour such as ‘mosh --client=mosh-client’. Etc. <nckx>isguixcidown: I answered that when you joined 😉 <nckx>Which server is still acting down? <lechner>nckx / never used mosh. what's the insight behind that command, please? <podiki>CI has been giving me lots more gateway timeouts the past several days <nckx>isguixcidown: Hm, OK, thanks for mentioning that. It should certainly be up. <nckx>It was (very very) down for a while earlier but whatever it is now counts as ‘up’. <nckx>lechner: It's just a contrived example based on a quick unpacking of the source and looking at mosh --help. The ‘--client’ is looked up in $PATH so wrapping would allow it to find its own client, whilst patching would not. <nckx>But really, the only way to know whether the original packager ‘did the work’ is to do the work, then compare the result, then test the result, maybe push the result, and then wait for anyone to complain that you broke their workflow. <nckx>It's not an easy ‘wrapping PATH bad’ checklist. <nckx>Oh, and hope that mosh upstream doesn't change the type of quotation marks used in the next release 😉 <lilyp>we should add "wrapping PATH bad" to our CI checklist on April Fools <lechner>nckx / PATH could be amended in the mosh binary <podiki>how about "rapping PATH bad"; that I think we can all agree on :) <lilyp>that's even sillier than writing a wrapper <nckx>My name is PATH / and I'm here to say / your binaries / are thatta way. <nckx>You're right that was bad. <podiki>and they say consensus building is hard <nckx>Well, it should be up, but apparently it isn't fully up for everyone. <nckx>JustQuickQuestio: ‘Not working’ how exactly? Do you get an error message and/or HTTP status code? <podiki>speaking of cuirass, most recent master evaluation failed (database busy) should that just be re-evaluated? <nckx>JustQuickQuestio: Thanks. <nckx>Unfortunately, I can't reproduce that here. <nckx>Yes, I think it only occasionally fails, and you just got {un,}lucky. <nckx>I wish I had a less disappointing answer. <JustQuickQuestio>no worries. just wasn't sure if we have a known Problem or if i am hallucianting and maybe somethign is wrong with my DNS <nckx>If this keeps happening regularly, mention it. <podiki>i haven't noticed anything recently on substitute downloading, but the web interfaces gives me more 504s than pages past few days <nckx>The head node went down earlier today but I don't see a link with this behaviour. <nckx>It's not like the logs are riddled with [relevant] I/O or checksum errors or whatever I'd look for. <nckx>(There were btrfs consistency errors, and they might have been related to the downtime, just not these 504s.) <lechner>something circular is happening with ci.ggo <nckx>(I did no more debugging than the aforementioned curl and frustration at my wasted time by the bogus 404s.) <lechner>updating substitutes returns 100% but never ends <podiki>maybe berlin is busy doing something (gc)? sitting very idle <lechner>Hi, anyone running Certbot wish you could specify more than one deploy-hook? <nckx>I think that's more likely a ‘simple’ hang (either a connection never succeeds, or never gets closed) than something truly circular. <nckx>Don't get me wrong, it's bad, just not circular bad. <xelynega>Anyone know where I should look to learn more about the linker wrapping that Guix does? <xelynega>I've been going down a rabbit hole thats going to require that `libnss_ldap.so.2` from the `nss-pam-ldapd` package is in the library load path for `passwd`, `sshd`, and whatever executable loads PAM modules during tty login, but I'm unable to find any information on "putting packages in load paths of other packages". Ive been looking through the source for ld-wrapper and trying manual linker flags, but the only way I've been able to get these tools to act <xelynega>correctly is to run them with `LD_LIBRARY_PATH=/run/current-system/profile/lib` . <nckx>podiki: It's not GC, but reads are indeed at ‘100%’ and nothing else is, so it's a good suspect. The culprit is guix publish… <lechner>xelynega / how about the regular LIBRARY_PATH? <lechner>also, that command defeats a lot of what happens in Guix! <nckx>‘100%’ is ~200 MiB/s, with very occasional peaks of ~500 MiB/s. <xelynega>I thats another environment variabl i presm it would work the same(ill double chec). My question is more "how would i set that for packages at build time" <xelynega>Sorry my chat messed up, going to test that environment variable. How would I apply that at build time in my config.scm? <lechner>Hi, is there a way to prevent an update to guix/build/utils.scm from causing a full bootstrap? Last time it took over twenty-four hours locally <lechner>xelynega / you really shouldn't. are you using the right version of the passwd tool? <lechner>also, PAM modules can take absolute paths <nckx>Hey nckx ya genious how about stopping your own btrfs scrub before measuring metrics. However, even now I/O in htop is still at 100%. <xelynega>Yes, but it is not finding `libnss_ldap.so.2` in the correct store path, since strace shows it only looking in the glibc store <lechner>that may be a packaging error in glibc <xelynega>And I have no idea how to correctly configure the system so that binaries that use PAM also look in the `nss-pam-ldapd` store for `libnss_pam.so` <xelynega>Oh, so it should be in the glibc store potentially? <lechner>i am not sure, but the PAM path should always point to your installation, not the store <lechner>PAM services should always be consulted in the system profile is, i think, what I meant to say <lechner>can you specify libnss_pam.so with a full path <lechner>can you specify libnss_pam.so with a full path <xelynega>Yea that's what I was thinking when I tested with the library path set in the environment variable, the system profile should be where it's looking for those. <xelynega>Not sure where I'd be specifying that, I've only seen the ENOENT from strace when passwd/sshd try to load libnss_pam.so <lechner>the PAM service will accept an absolute path into the store <lechner>alternatively, the .so can be installed into the system profile <xelynega>Yea it is in /run/current-system/profile/lib for another test I did, but it doesn't look like Pam looks there by default <lechner>it may not. we have problems on reconfigures <lechner>you can probably see some absolute paths in your login service <xelynega>So I'm going to test this, but I have one question. If the PAM service specifies these paths then why would setting the `LIBRARY_PATH` resolve the issue at runtime <xelynega>And I'm building a VM image from this and running it, so hopefully any reconfigure issues won't affect it <lechner>probably. LD_LIBRARY_PATH certainly would, but either is a very large gun <attila_lendvai>ACTION is dismayed that his home reconfigure wants to build several large packages locally <xelynega>Gotcha, yea I tested the `LIBRARY_PATH` and there were a few NOENTS in the strace but it eventually found the library in the store path(as opposed to ld_library_path which immediately found it, but in the system profile which isn't as clean) <lechner>xelynega / here is an example for how get the absolute path <attila_lendvai>oh, there was some outage... i thought it's the usual lack of a staging branch to help the builders catch up. i pulled earlier today. <xelynega>Not able to try it right away, but I'll let you know how it goes when I'm able to apply it. Thanks for helping me underdstand this lechner . <xelynega>lechner taking a look through the nclcd source, it already uses absolute paths for the pam_ldap.so module <xelynega>Would nsswitch.conf be able to do the same for the libnss_ files? <lechner>xelynega / is the use of absolute paths *inside* nslcd a packaging error? <lechner>not sure about nsswitch.conf. never liked that file and only looked at it twice since 1990 <xelynega>No, the error that I see is that without specifying the LIBRARY_PATH at runtime, nothing can find libnss_ldap.so.2 despite it being in the system profile <xelynega>passwd, sshd, su(seen with strace) and assumedly the tty login process <lechner>okay, sorry. a cat is blocking my monitor. let's go over it one more time. where does that pam module come from, and in which service is it listed. where is that service stored? <tjout>Ok I give up. Been looking really hard at the manual but can not find how one would use a keyfile for LUKS devices. Is this not supported (yet)? All issues I found seem to say so. <NoahMetz>I'm xelynega, just took off in a plane and bought wifi on laptop and don't have my nickserver password :/ :/ <Kolev>How do I get a container to write to its /gnu/store? <lechner>i'm glad i'm not traveling today. hope it's a pleasant ride <NoahMetz>Haha yea, everything has been on-time so far so nothing to complain about yet. <avp>Hello, Guixers! Are here any of Guile-ZLib developers? Or maintainters, for that matter. <nckx>tjout: There is a patch to that effect on the issue tracker, though, I think. <tjout>Yeah I read about this. Seems like a concern about security when putting the file in initrd. <nckx>avp: Ludovic is civodul (it's encrypted). <avp>civodul: Oh, I see that you are one of Guile-Zlib maintainers. :-) What is the proper way to file a bug report for Guile-Zlib or even a patch? <nckx>tjout: Yes. It's not insurmountable, but something to look out for that all store files are world-readable, no exceptions. <vivien>lilyp, I will check the fix as soon as webkitgtk-for-gtk3 is done! <nckx>And everything that Guix builds ends up in the store. <sarg>does anyone have a shepherd service definition to run a docker container? And then another one for a libvirt domain? <NoahMetz>And for my config, what I've got is the `nslcd-service-type` with the following config(with domain replaced for clarity): <NoahMetz> (pam-services (list "su" "login" "sshd" "passwd")) <NoahMetz> (filters (list '(group "(objectClass=posixGroupAux)"))) <NoahMetz> (binddn (or (getenv "LDAP_BINDDN") "")) <avp>peanuts: Thanks! This requires registration though. I was thinking about something like a mailing list for patches. <avp>lechner: Turns out peanuts is a bot. But thanks anyway. <lechner>in that case, it pulled the HTML title from the URL i sent you <Kolev>I also found out that entering a container is rather inconvenient. I have to copy and paste the command from the container output, and I have to run the container directly from /gnu/store. <nckx>xelynega/NoahMetz: You were quieted above (by a bot) for flooding (posting an unconventional number of lines in a short timeframe). Use paste.debian.net for code snippets and other messages over 3-4 lines. <Kolev>This is much less convenient, compared to `toolbox enter` with Podman tools. <lechner>Kolev / does the container output produce only the command you hope to run, or also other stuff? <nckx>I/O on berlin is no longer pegged at maximum, although it still occasionally maxes out. I wonder if this will have any effect on reported bugs. <xelynega>Is linking to personal git allowed? Or is it preferred to use `paste.debian.net`? <nckx>Whether the ‘0%’ issue reports will stop now. <nckx>xelynega: The reason we recommend p.d.n is because it doesn't require JavaScript, host dodgy ads, etc. <lechner>do people report infrastructure problems as software bugs? <nckx>If your Git Web UI doesn't either, that's fine. <nckx>lechner: I meant here, in the channel. <nckx>Although, yes, they do report them at issues.guix as well. <nckx>I'm sympathetic. Arguably Guix could better handle/report these errors. <Kolev>But yeah, I wish `guix system container` had a `toolbox` style utility. <lechner>that's because we only use one debbugs "package" <nckx>I think it's fine and that an extra guix-infra package would not be worth it. <tjout>nckx I my case that would not be a problem. I have the keyfile bytes in some free space on a specific usb drive that I only plug in during boot. In the past I had crypttab read that from a known offset from this device. <nckx>Leaking ur secret sector offsets. <lechner>nckx / for visibility, the mailing list might be better <nckx>I think empirically this channel has proven to be the most visible option. That's not a value judgment on your opinion, I just think it is what it is. <nckx>I was just typing out how biased I am. <xelynega>lechner Here's the `nslcd-configuration` I pass to the `nslcd-service-type` that's in my system config( https://paste.debian.net/1299298/ ). From the source this extends the `pam-root-service-type` with an extension that has the absolute path of the `pam_ldap.so` library. <lechner>xelynega / whoops I got confused. you are having issues with libnss_ldap.so not libpam_ldap.so, right? <nckx>lechner: There's guix-sysadmin@ but I really think that Guix itself should do more to detect these bugs, not just hang or print a backtrace. *Then* it can tell users where to report bugs, because that's honestly a detail. I say this without volunteering to fix the client, though, so take it FWIW. <xelynega>Oh sorry yea, the `libnss_ldap.so` is the one that `strace` shows ENOENT for <xelynega>*without setting the library path to the system profile library path explicitly with overbearing environment variables <nckx>s/detect these bugs/detect networking failures, no matter what the cause, because it's not good at *any* of 'em :)/ <xelynega>With `LD_LIBRARY_PATH=/run/current-system/profile/lib` set, `passwd` and `sshd` find `libnss_ldap.so.2` in `/run/current-system/profile/lib`, and with `LIBRARY_PATH=/run/current-system/profile/lib` it's found in `/gnu/store/pl80w9p6dgi3iapgwb71f720ngq0ckhn-nss-pam-ldapd-0.9.12/lib` <xelynega>But I'm not sure what needs to be fixed in the .scm files to make this happen the "correct" way(and make tty login find the library correctly) <xelynega>I was reading about the ld-wrapper and it seems like it would either need to be in the `ld.so.cache` for every executable that uses it, or in a directory that ld.so always reads from.(and I presume the glibc store is searched by the dynamic linked since `strace` shows it looking in a few different subdirectories there). <xelynega>In this case do you know if there's a way to either extend ld.so that it searches another path, or add to the path that it does search? <lechner>i.e. looking in /run/current-system/profile/lib <xelynega>Do you think I would then have to apply the same patch to `openssh` to have `sshd` find the path? <sneek>Welcome back xelynega, you have 1 message! <lechner>xelynega / no, i believe binutils ships ld.so <avp>I just realized that I just started a discussion about Guile-ZLib in a wrong chat; that meant to be in #guix. Sorry, everyone. <xelynega>lechner gotcha, I guess I was confused on if this was patching passwd/su directly but those are in `shadow`/`coreutils`. Morning brain. <avp>lechner: Oh goodness, I mean #guile <lechner>avp / no worries. we're one big family <avp>Besides, recently civodul have merged Yggdrasil 0.5.2 update into GNU Guix, so the Yggdrasil Guix Substitutes server maintained by Andrew Tropin (abcdw) is now accessible to the new version of Yggdrasil network peers. \o/ <xelynega>Haha yea, just landing so I'll let you know how it goes when I'm able to apply that. <xelynega>Out of curiosity what would be the long-term solution if this does work. Is there a way to maintain patches that are applied to the guix channel in config.scm, or would I have to patch the channel before updating? <xelynega>Got it, thanks for all your help with my understanding of guix :) <lechner>unless you can find a configure option (or get one into upstream) <lechner>it may be worthwhile to look how Nix does that. with it's larger user base they may have fixed that already <lechner>xelynega / no worries. please feel free to hang out here when you have time in order to help others <xelynega>And I'll see what Nix has done that's a good point, I've heard of more corporate uses of nix so wouldn't be surprised if someones needed to integrate nss extensions. <lechner>xelynega / i may also benefit. i gave up a lot of goodies since switching from Debian, such as my LDAP setup <lechner>xelynega / i may also benefit personally. i gave up a lot of goodies since switching from Debian, such as my LDAP setup <xelynega>lechener / yea I'm a few steps behind but in the same boat. I have LDAP and kadmin5 servers I want to take into the guix fold so I can sleep better at night. <xelynega>One more thing I'm looking at contributing once I've got this setup is some minimal/different configs and docs for getting LDAP auth setup in guix. <xelynega>That would be good. I picked mit krb5 for no particular reason(probably higher up in search results), not sure of any differences(guix support or otherwise) <lechner>i ran krb5 on Debian but the usertools aren't great. i figured i would upgrade with my switch to Guix <lechner>i used krb5 for fifteen years but haven't done much with heimdal. it's not that useful without LDAP <vivien>I’m about to publish the remaining GNOME 44.6 updates, but I still haven’t packaged xdg-desktop-portal-gnome <Kolev>lechner, another Codeberg user! 😀 <lechner>Kolev / i love codeberg! i only wish there themes had higher contrast because my vision is so poor <vivien>The answer is obviously yes, because it is an official core application, but then we don’t have gnome-logs either so… <Kolev>vivien, it's too bad GNOME Software doesn't work with Guix. <vivien>Kolev, true, but I don’t think we should wait for this one either! <xelynega>Whelp got to hop off here for a bit, but thanks again for the conversation and knowledge. Have a good Sunday if I don't talk to you all again. <Kolev>GNOME Software now supports user-installed packages. It shouldn't be hard in theory to support Guix in Software. <Kolev>xelynega, have a pleasant day! <vivien>The GNOME Software issue is real, but I would also like to say we nerds care a lot about how applications are installed, way more than users who have specific jobs to do with the computer. <vivien>I would say we underestimate the number of people who would be happy spending some extra time installing their productivity programs once, and not caring about installing packages ever again. <ieure>One of my favorite things about Guix is that I don't need any other package manager. No pip, no bundler, no npm, no flatpak, no appimage, no snap, no straight.el, no package.el. <ieure>Guix does it all, and does it better. <ieure>Hopefully that situation can improve in future. <nckx>According to a mail I just moderated, Nix simply parses cargo.lock and downloads everything for you. I didn't verify that claim but OK wow wild. <efraim>sounds pretty similar to how arch does it <nckx>As long as it's checksummed correctly, go nuts. <nckx>now I reminded myself that Go exists. <efraim>rust at least uses semver for crates, every go package commit is a legitimate input <nckx>Oh, gnu.org proper? I'd missed that, thanks. <nckx>(Mumi runs on berlin though, so it should have received more than a tug when I rebooted.) <nckx>Wait. It's not still supposed to be fed by an rsync running out of rekado's bedroom is it. <lechner>that's i don't know but I have an rsync now also <vivien>ACTION had to do M-x info instead of browsing the manuals on gnu.org <nckx>Oh good lord I think it is. <nckx>it's literally a while loop running in screen (or in my case, dtach). <lechner>i guess you could have the files from me also, every five minutes <nckx>That's not the issue, but thanks. <nckx>ACTION numbly hits ^\ and puts another coin in the sysadmin swear jar. <nckx>‘The Mumi service has been started.’ <Kolev>How do I let a container have its own writable /gnu/store? <Kolev>Or, more generally: How do I install packages inside a container? <Andronikos>This week was a talk in London on how you can review patches. Someones knows if it was recorded and may have a link? <lechner>when (and how) does Guix trigger a full bootstrap after the sources have changed, please? <lechner>i still get 100% but with a loop from substitutes <podiki>nckx: thanks, see full workers now on CI and not getting timeouts on the webpages <nckx>Niche audience, but I took the opportunity to upgrade the guixp9 node and kick it so now only one (aarch64) builder is idle. <nckx>Apart from the btrfs errors? <mirai>lechner: hmmm… I wonder if there's a cleaner way to do what you're proposing (e.g. via service extensions) <sneek>mirai, lechner says: / thanks! <sneek>mirai, lechner says: / would you mind if I change %certbot-deploy-hook back to %nginx-deploy hook in fec8e513803970f5105817ae80b696605bbf3b03 ? certbot accepts multiple --deploy-hook options. I have a patch to make 'deploy-hooks' a list and in that case, the names can be service specific.thanks! <nckx>I'm still not sure how serious to take the btrfs errors from a short-term perspective, whether they have anything to do with current issues or are just latent corruption. <mirai>when I renamed the nginx-hook to certbot-hook I had my custom one in mind (it's a hook that not only restarts nginx but also takes care of dovecot and smtpd) <mirai>so it seemed better to rename it to something more general <mirai>though I think your idea of turning that field into a list + making certbot service-extendable (via simple-service perhaps?) might give a better design <civodul>nckx: so we have “issues” beyond the btrfs errors? <nckx>It's the ‘so’ that confuses me. Do we? <Kolev>Is it safe to share the host's /gnu/store with a container? <Kolev>I want to be able to install stuff inside a container. <nckx>civodul: I'm mildly surprised that the Mumi bug rsync ‘service’ isn't an actual service, but maybe it is & I missed it. It's not a regression though. <nckx>The ‘Cuirass workers need occasional kicking’ issue seems to be resolved 👍 <civodul>nckx: yes, it should be fine, except maybe on overdrive1, which runs Cuirass 1.2.0, which had a regression… <civodul>re mumi + rsync, i have no idea how this happens <nckx>Ah, that explains overdrive1 being idle, thanks. <nckx>civodul: The last state of the art of which I was aware was a bash while loop running in screen… So that's what's up now. Whoever previously rebooted berlin would have presumably needed to know that, or we would have noticed? <civodul>nckx: oh, didn’t know that; we should set up a service running rsync <Kolev>How do I make a container's /gnu/store usable? <nckx>civodul: Ah, it's probably because it requires a secret. <nckx>It's reasonable to treat everyone with an account as a trusted sysadmin (duh) so storing it locally should be OK, just not in the git repo. <apteryx>civodul, nckx we have an longstanding bug ID to add a proper rsync job :-) <apteryx>I think that's about the only important bit not captured in our config