IRC channel logs
2022-12-21.log
back to list of logs
<vivien>When I ping git.savannah.gnu.org on my machine, I get to ping 78.46.90.98, but when I ask the DNS, I get 209.51.188.168 as a response <vivien>Why does ping not use the IP address returned by the DNS? <nckx>I guess they don't handle ICMP properly, or some other weird sortabug. <vivien>My ISP is not austrian, but yeah, on my other ISP everything works as expected <nckx>78.46.90.98 is proteus.info.at. <vivien>So it’s normal that the IP address that appears in the ping output might not be what I sent my packets to <nckx>You'll often (well, hopefully not too often) see your local gateway in there, for example. <Guest30>icmp packets aren't authenticated or protected in any way, so any hop between you and the target server can intercept the response if it feels like it <vivien>Thank you a lot, so I guess the ISP is running into trouble <nckx>vivien: Did ping say ‘PING git.savannah.gnu.org (78.46.90.98): 56 data bytes’? <vivien>PING git.savannah.gnu.org.eu (78.46.90.98): 56 data bytes <vivien>64 bytes from 78.46.90.98: icmp_seq=0 ttl=55 time=52,130 ms <nckx>vivien: WTF. This is not what I meant above. This is worse. <vivien>I don’t have the problem at all for gnu.org <Guest30>confirming that `gnu.org.eu` resolves to the ip address you describe: <nckx>Do you have a ‘search’ line for .eu set up, somehow? <vivien>I just have: # Generated by 'static-networking-service'. <patched[m]>How can I run guix shell to get an environment in eshell? Currently it starts up zsh, which is my users default shell. <rekado>mumi 0.0.3 is out; will deploy to issues.guix.gnu.org tomorrow <vivien>Oh now I see the ".eu" in the ping output (it’s a bit late here) <Guest30>vivien: are you running these from a consumer ISP connection or is this on a cloud machine <nckx>vivien: So if you ‘guix shell ldns:drill -- drill @192.168.10.1 git.savannah.gnu.org’, what does it return? <nckx>A sort-of-consumer-sort-of-VPN-ISP? Fun. <vivien>That’s a bit weird since I think the goal of a VPN is to be an ISP <vivien>Yeah but they let me fix the reverse DNS <vivien>I guess I have to see with them directly, thank you in any case <nckx>vivien: If you find out the reason, could you share it? Unless Guest30 has an idea, I'm lost. Why would they do this. <Guest30>vivien: if the web services you're using have nothing to do with `info.at`, it might be a local configuration issue causing *.eu to be appended to the request. The reason you're hitting that IP is beacuse `info.at` is a TLD registrat for *.eu, and has `org.eu` (the domain name, not tld) set to wildcard redirect to their site <vivien>Guest30, I suspect that, but it’s weird that it only happens for git.savannah.gnu.org and not savannah.gnu.org. <vivien>(the final dot is here to end the sentence) <Guest30>can you try a few other "*.org" domains? Preferably with 2 subdomains, like git.savannah.gnu.org? <vivien>Maybe that’s because I query git.savannah.gnu.org a lot and it gets cached in weird places <pkill9>why does guix create sooo many grafts when you're updating etc? <Guest30>pkill9: because the package dependency tree is really big <AwesomeAdam54321>pkill9, you can use the --no-grafts option, in which case it'll build the package and not just apply grafts on top of the package with substitutes <vivien>So, no, this is not a problem with only ping. If I do telnet git.savannah.gnu.org 80, telnet tries the wrong IP. <Fare>I'm failing so far at running Guix on a pinephone pro. Is anyone successful at that? Or else NixOS? <vivien>So I guess this is a problem with the system, if it does not respect what the DNS tells the right IP address is <nckx>I'm sure it will happen with anything that uses your system's resolvel. <Guest30>vivien: do git and web browser connections resolve correctly? <nckx>Still sounds like it's searching eu. <vivien>The whole thing is I noticed the problem because the cron job to sync the guix repo started to fail a few hours ago <vivien>I can’t try a web browser though <nckx>They usually implement their own NIH resolver anyway. <vagrantc>Fare: guix was the main OS i ran on pinebook pro till about a year ago, but haven't used it recently <nckx>Does ‘sudo herd invalidate nscd’ do anything interesting? It's the name service cache. <vivien>It prints nothing, and ping and telnet still try the wrong IP <lechner>vivien / how do you activate the vpn? <nckx>It's not supposed to print anything. <vivien>lechner, it’s set up on the router <vagrantc>Fare: you might have to get fiddly defining modules in your initrd ... upstream linux tends to change those names around all the time between major versions and guix initrd doesn't dynmically probe kernel modules <nckx>(There's a ‘statistics’ action that does, if you're interested.) <Fare>vagrantc: I'm failing to boot into the image from guix.gnu.org. I tried cross-installing from debian, but the reconfigure fails towards the end. Do you have a working recipe to share? <lechner>vivien / do you have a /etc/resolv.conf from the router? <vagrantc>Fare: i could dig up a config that worked last year ... <Fare>I was hoping to turn the pinephone into my "secure device". <Fare>But I can't even get it to boot into a decent console. <vivien>But on the router, pinging git.savannah.gnu.org uses the correct IP <nckx>ACTION now not so sure invalidate nscd actually does something… <vivien>Maybe that’s because it’s not going through the VPN though <lechner>which resolver is running on the router? <vagrantc>Fare: oh, i misread you ... i have never tested on pinephone pro, pinebook pro <vivien>The router is the librecmc distribution <vagrantc>Fare: they are somewhat similar, but probably different enough to matter <nckx>vivien: If you think (system) caching is to blame, if you ‘herd stop nscd’, does that change anything? <Fare>probably similar enough with respect to guix config. <Guest30>vivien: mind running 'guix shell bind:utils -- dig git.savannah.gnu.org' <nckx>vivien: Do the ‘wrong’ ping/etc. look-ups happen on the router as well? <vagrantc>Fare: the display is going to be significantly different <nckx>Guest30: I already asked that IIRC. <Fare>There might be differences in kernel configuration, that I can try to solve by asking other pinephone pro users (not necessarily guix) <vivien>nckx, yes it does, with nscd off the correct IP is used (and telnet even correctly uses an IPv6) <Guest30>I know nckx had you run drill before but i'm less familiar with the ldns utils, just trying some sanity checks <vagrantc>Fare: i suspect there are patches not yet mainlined for the kernel too <Fare>how easy is it to use a non-Guix kernel on Guix? <Fare>I mean, non-Guix as in Mobian or Arch, not nonguix. <vivien>The router pings are OK and dig gives me the correct answer <lechner>did we determine that nscd was to blame? <vagrantc>Fare: you can install a minimal OS and then use guix for most of your packages... <vivien>lechner, I think that the conclusion is near <vivien>I don’t know how nscd works to be honest <nckx>It appears that nscd was caching bullshit, but if (and how) it could be to blame for the bullshit is unclear. <Fare>I'm afraid of killing my current mobian installation. Somehow, I haven't managed to boot from the MMC slot since. Now trying kexec, and failing. <vivien>Can I expell the bullshit from nscd? <nckx>And it confirms that our ‘invalidate nscd’ action is also bullshit, or at least doesn't do what's expected. <Fare>vivien, back in my debian days, I had to restart nscd, or even remove it (which might not be possible today due to how it's used) <vivien>That’s a better word for the situation lechner <nckx>That's exactly what the herd action is supposed to abstract. <vivien>What package provides the nscd program? <vivien>(I restarted nscd and now the incorrect IP is back, but it’s not for long…) <nckx>I forgot: did you invalidate the cache? <vivien>It’s a good thing that ci.guix.gnu.org is not blocked <nckx>You could always emergency-add it to /etc/hosts :) <vivien>nckx, I ran: # herd invalidate nscd then tried again and the wrong IP was still there (I retried again just now) <nckx>That's because I'm fallin asleep and forgot the hosts (herd invalidate nscd hosts). <Fare>vivien: have you tried restart rather than invalidate ? <nckx>Or host. But probably hosts. <vivien>Oops the nscd -i hosts completed in the mean time, so I can’t try again sorry <nckx>That's OK, it invokes the same thing. <vivien>Fare, I restarted it after I stopped it to debug the issue <nckx>Fare: It's counter-intuitive, but restarting the service wouldn't solve it. <vivien>I also rebooted the whole computer <Guest30>i'm still confused how *.eu got appended to the cache entry in the first place though <Guest30>good to hear that the issue is resolved though <vivien>My computer has a name in the .eu zone <Fare>wouldn't that flush the cache? or is there a persistent on-disk cache? Then stop, rm -rf, start? <nckx>Yes. Hence --invalidate. <nckx>ACTION really going to crash now. <vivien>Sorry for keeping you awake, and thanks a lot <AwesomeAdam54321>I found out that IceCat includes a bundled cairo under the gfx directory with a bunch of patch files <apteryx>mbakke: I think I've gotten to grips with modify-defconfig & thus probably customize-linux <apteryx>long story short: it's defconfig-centric, and if you use CONFIGS you must carefully replicate the changes that menuconfig would have made, taking care of dependencies (make savedefconfig to compare) <AwesomeAdam54321>I think the IceCat --with-system patches are very useful for other systems and should be applied to the source <apteryx>nckx: you have to pass a table to invalidate to the invalidate nscd action I think <apteryx>we should put bash completion to all our shepherd services <AwesomeAdam54321>the bundled cairo only includes the parts that are patched with patch files <apteryx>nckx: re #60068, the problem it solves for me is that I couldn't use 'guix pack's to help me bootstrap guix-install.sh otherwise <apteryx>(it'd say something like "there's already a guix installation! aborting!" duh) <oriansj>apteryx: examples would be enough to make discovery much simpler <apteryx>rekado: now you can test 'u-boot' as a command from the comfort of your desktop (#60231) <apteryx>electron app bugs? didn't know we had an electron app in guix <johnabs[m]>And Julia is upgraded and fixed, bless whoever did that upgrade, this is phenomenal <johnabs[m]>apteryx: Yeah, things like signal desktop and element are both electron apps IIRC <johnabs[m]>And they both had hardware accel issues on my machine until today! <AwesomeAdam54321>The icecat unbundling patches haven't been updated yet, so I'm trying to do that. <apteryx>johnabs[m]: OK, you are probably using channels <AwesomeAdam54321>johnabs[m]: IceCat is a libre web browser derived from Mozilla Firefox. It's special in Guix because it's maintainer is also involved in Guix <AwesomeAdam54321>It's most likely one of the things that needs to be done for IceCat 102 to be released officially <vagrantc>apteryx: i don't understand c04528d2a2597d79278833f3607c806278253446 where you renamed u-boot-am335x-boneblack ... there used to be a u-boot-am335x-boneblack configuration upstream, and this package adapted that one to fit in the same space as the old upstream one <vagrantc>apteryx: adding the -evm in the name just makes it a whole new thing, rather than a stand-in for an old thing ... <vagrantc>though honestly, i'd be surprised anyone could usefully use the beaglebone black with guix, has no more than 500MB ram... <vagrantc>maybe something in the way the raspberry pi patches refactored some of those packages made it strange? <vagrantc>well, that's the other good thing about the platform, not particularly great i/o ... either eMMC, microSD or USB->disk adapters <omlet[m]><efraim> "unofficial guix riscv64-linux..." <- Star five riscV its freedom drivers? <AwesomeAdam54321>omlet[m]: It's still a bit early to tell, but as long as you avoid proprietary extensions to the riscv ISA it gets pretty close. Maybe 4 stars <omlet[m]><AwesomeAdam54321> "omlet: It's still a bit early to..." <- Good <rekado>new mumi is now live at issues.guix.gnu.org <omlet[m]>Is there a problem that distrobox is not officially packaged for guix? <rekado>no announcement other than the git log <rekado>I don’t feel like also maintaining a NeWS file <omlet[m]>rekado: I speak about legal problems for add <rekado>omlet[m]: if you know of any obstacles please add them to the issue <omlet[m]>at most, it would feel good to change the image of the debian by the u fedora then create an image of the trisquel, but for the rest, it is basically the docker <omlet[m]>I'd just like to know why, even if I'm a common nurse in the guix who doesn't know how to package or compile, I'd like to pray the distrobox in the guix and not have to migrate to the nixos. <rekado>omlet[m]: you don’t need to migrate to nixos just because a patch is not applied <rekado>omlet[m]: you can easily add this package definition to a local package collection and use it from there. <PurpleSym1>rekado: One oddness about the new design: The dark mode button only appears after the QA button loaded – which sometimes takes a few seconds. <rekado>PurpleSym1: yeah, just noticed that <rekado>the dark mode thing is activated on window load, and the QA button is loaded eagerly <rekado>should be done asynchronously instead <rekado>that would also prevent that flash of rendering in light mode before switching back to dark mode <rekado>I would have changed the button instead of the hook, but yes, hooking it to a different event would probably be enough. <unmatched-paren>congrats on the 1.4.0 release, which i've just noticed happened on sunday! :) <rekado>omlet[m]: you can either get the source code of Guix itself and apply the patch there, or you can take the package definition and paste it to a file, then install from that file. <PurpleSym1>rekado: You might want to add `backdrop-filter: blur(2px);` to the top `<nav>` to blur the background slightly. Works only in recent Chrome/Firefox though. <sughosha>Hi there, has anyone installed plymouth and made it working? <unmatched-paren>i can't remember who, and i don't know if they managed to get it working <rekado>itd: consider pinging the “haskell” team <rekado>use ./etc/teams.scm list-members haskell <itd>Thanks, I'll look into it. <Parnikkapore_m>Hi, I'm running Guix on a foreign distro and am using fish as the default shell. How should I patch config.fish etc. to initialize $PATH etc. <tex_milan>Hello, how to get path to installed package in shell? I know I could ls /gnu/store/*PACKAGE*/ but that lists all incarnations, not the one really used. I'd like some simple command like guix show-path PACKAGE. Any idea? <unmatched-paren>Parnikkapore_m: you probably shouldn't use fish as the default shell with guix <unmatched-paren>tex_milan: i don't quite understand what you mean by "all incarnations" <tex_milan>unmatched-paren: thanks! exactly what I was looking for! <Parnikkapore_m>unmatched-paren: I used to do that, but the terminal in my IDE didn't switch and I don't want to config everything 😔 <Parnikkapore_m>anw I adapted the config.fish from the fish guix package and that seemed to work well, but I haven't tested in detail <nckx>unmatched-paren: I'm sorry. <nckx>I tried to edit my top comment but it appears that's not possible. Oh well. Thanks. <rpana>Hello community, I am in the process of migrating from NixOS to Guix :) , lots of fun so far <rpana>A question, how can I get Emacs from master in Guix? <rpana>I found emacs-next, but this is not the latest version <rpana>It is 29, in master we have 30 already <rekado>rpana: you can use package transformations <rpana>:rekado thanks, I will read about that then <flypaper-ultimat>rpana: e.g. guix build emacs-next --with-commit=emacs-next=ad5a67996ddf23df904c09165475759e2e0a68b1 <axet>Hi! Can I install guix into chroot environment? looks like guix system init requires a lot in scm file to do so <axet>similar command as I do when run 'debootstrap /bookworm' <flypaper-ultimat>rpana: if you want to use it in your manifest file, the info page `info "(guix) Defining Package Variants"` is useful, especiall the the part about `options->tranformations`. There you'd do in place of `with-branch`, `with-commit`. <rpana>:flypaper-ultimat: thanks for the advice, very useful <AwesomeAdam54321>How do I use old style inputs with new style inputs? All the examples of including patches as (native-)inputs have all of them listed in the old style <AwesomeAdam54321>I got an error that rust was an invalid input for icecat because it's in the new style while the patches that came before were in the deprecated style <lechner>axet / Guix is so isolated, you probably do not need chroot <lechner>AwesomeAdam54321 / i think you just list the variables, instead of the labels plus <efraim>rekado: that machine is long gone. I could probably spin up a VM with the liquorix kernel and test it out there. <efraim>well the machine physically is in my drawer but doesn't boot anymore, and I've repurposed the OS drive since then <winter>anyone know how I'd change the Linux build in the install image so that it's built with CONFIG_EFI_STUB? not really sure where to begin <winter>(it doesn't boot under GRUB+aarch64 otherwise) <lechner>i am surprised we do not build it like that already <lechner>but you should not need the EFI stub with Grub; only with something like rEFInd <winter>GRUB checks for the existence of a few magic numbers <axet>@lechner I need chroot not for isolation, but for installing fresh OS. That the way I install debian: using debootstrap <lightbulb>axet: Error: "lechner" is not a valid command. <winter>which we currently don't build it with the flags to get them <winter>(see `grub_arm64_uefi_check_image`) <winter>i have no clue what the image that's currently built even is, though <lechner>winter / the linux image boots on my system under grub <lechner>axet / please describe your use case in greater detail <axet>@lechner install guix in /guix folder, chroot /guix - continue configuring it <lightbulb>axet: Error: "lechner" is not a valid command. <lechner>winter / how is anyone else booting it on aarch64? <lechner>axet / you don't need the at symbol. it's confusing our new bug bot <nckx>grep EFI_STUB $(guix build linux-libre --system=aarch64-linux) → CONFIG_EFI_STUB=y, but no, I haven't actually booted the aarch64 image (yet :) <nckx>winter: Which kernel are you booting, exactly? <axet>lechner ah it is a bot. I thougth someone joking on me <winter>nckx: i'm just trying to build/boot the ISO installer image on aarch64 <lechner>axet / you are not off the hook yet. we are funnier than our bots <nckx>winter: OK, but what exactly are you building? <lechner>axet / why not install the 'guix' executable that comes with your distro? <winter>but seemingly there's some config flag missing that builds a completely different image type than GRUB expects. one of the errors mention that flag, but i guess that's not the issue <nckx>I'm missing way too much info. <axet>lecher I do have guix, and now I want chroot, then boot into new /guid <nckx>I'm currently building ‘guix system image -t iso9660 gnu/system/install.scm --system=aarch64-linux’ to see if it stubs. Let me know if that's not what you're doing. <winter>nckx: I'm just running `guix system image -t iso9660 gnu/system/install.scm` from the root of a Guix checkout. <AwesomeAdam54321>lechner: Thanks, it turns out I didn't need the comma in front of the variable part <nckx>Nice, even lines up perfectly with my font :) <winter>It builds successfully, but it does not boot, giving that invalid magic number error (which shows that the wrong image type is being used). <lechner>winter / is your setup getting confused between bzImage and initrd? <lechner>axet / dual boot, or use at the same time? <axet>how can I install guix into /guix? <winter>lechner: i have no clue, the GRUB options look correct, so i doubt it <winter>and like I said, the kernel image does look incorrect, looking at the hexdump versus what GRUB expects <nckx>winter: All Guix Systems are installed into a subdirectory, that's the FOO in ‘guix system init <system.scm> FOO’. <nckx>Sorry, meant axet, not winter. <winter>lechner: I'm trying to build the install image. <winter>And that's what happens when booting the successfully installed image. <lechner>winter / do the bus size and byte ordering of your installation media match the desired deployment? <winter>lechner: i have absolutely no clue, i'm building on aarch64 for aarch64. <rpana>Another question, how can I make this simple guix-home config https://paste.debian.net/1264839/ pull my Emacs configuration from a git repo? I assume using a function alternative to `local-file`? <nckx>lechner: Could the global parsing of @-‘commands’ be disabled? Newcomers mistakenly typing ‘@nick’ is too common. <rpana>Or in other words, is there a function to clone a remote with guix? Something like the `fetchFromGithub` from Nix... <nckx>Sounds like (git-checkout (url "…")). <nckx>I don't use guix home though, but it should work. <pkill9>does anyone who is forced to use microsoft teams find that it crashes on ungoogle-chromium? <lechner>@nckx / lightbulb should be quiet now, but i think it's still banned <nckx>It's not banned, merely tied up in a corner with a sock in its mouth. The difference is legally significant. Thanks! <lechner>yeah, sorry about that. it's my first time running a bot <pkill9>does anyone know how to possibly fix the fact that gnome-shell needs to be restarted for launchers to update after changes to the guix profile? i'm guessing gnome-shell watches the real path from symlinks, instead of just watching the symlinks themselves <rekado>lechner: are you using guile-irc? <rekado>it’s what we use for goggles-bot <lechner>rekado / thanks for the hint! i can't wait to migrate away from limnoria. will look into it <lechner>no, but python and i are not on good terms <lechner>plus, as i mentioned yesterday, Limnoria loads plugins dynamically. i believe it means i have to create a custom package definition to make sure that the SOAP module needed by the plugin (but not available in the bot as we ship it) is available http://paste.debian.net/1264845 <lechner>in addition, the recommended way to configure Limnoria is via online commands, which is not declarative at all <rekado>lechner: FYI you can use the graphql endpoint on issues.guix.gnu.org to fetch issue info <rekado>with “req” containing this: {"query": "query { issue(number: 666) { title number open } }" } <lechner>rekado / maybe this is not the time to mention it, but after years of responding to bugs in another distro i have two suggestions. first, any chance, guix might embrace bug identifiers in base64 or a similar encoding? second, can we pick another shorthand notation besides #XXX? <lechner>i.e. another symbol, or set of symbols like /XXX/ <rekado>lechner: this is outside of our control. The numbers are what debbugs provides and uses internally. <rekado>there’s no good reason why these should be numbers only (debbugs treats them as opaque identifiers), but that’s not something we can change. <rekado>(we = downstream users of a shared debbugs instance) <lechner>there is a one-to-one mapping we could use unilaterally, and i am hoping we may not use debbugs indefinitely <rekado>currently mumi’s database is not precious; it is generated entirely from debbugs messages. As long as we’re using it just as a frontend I’d rather not introduce precious data that we have to keep safe. <rekado>especially for bug URLs we want to guarantee that identifiers never disappear <rekado>mumi is not currently set up for this kind of operation. <rekado>if mumi ever handles incoming email it may introduce different identifiers, but until then I’d rather keep it stupid. <nckx>winter: It took a while to build (QEMU), but I really can't find any evidence of the kernel lacking EFI stub support. GRUB not booting kernels without it is also extremely implausible. I think you're barking up the wrong tree. <winter>nckx: I'm not really sure how. The kernel image that Guix is producing will not boot with GRUB, it seems that it's building the wrong type. <winter>It looks for some magic (ascii ARM64 and then another character), which the Guix kernel image doesn't contain, while the e.g. NixOS image does. <lechner>from grub's perspective, you may have the wrong processor <winter>nckx: Looking at how we (NixOS) build the kernel, nothing really stands out. The image type is set to `Image` like Guix, and EFI_STUB is set. <winter>But something is definitely different between the two so that NixOS builds what GRUB expects. <nckx>Do you happen to already have the magic handy? <nckx>‘MS-DOS executable PE32+ executable (EFI application) Aarch64’ look GRUB, look. <winter>nckx: #define GRUB_ARM64_LINUX_MAGIC 0x644d5241 /* 'ARM\x64' */ <winter>the check for that is what's causing the exact error i'm receiving <winter>theres just another check for the efi stub one <winter>so i was curious if that was related <nckx>OK, I feel a bit less stupid now: <nckx>ChangeLog: Change GRUB_ARM64_LINUX_MAGIC to GRUB_LINUX_ARM64_MAGIC_SIGNATURE. <winter>Ah, yeah, sorry, I'm using some old GitHub mirror to quickly search. <winter>Were you trying to find it before? <nckx>Yeah, but also on a mobile 😛 Horrible mess. <efraim>back to working on seabios, so many different architecture combination options to check to make sure it works <jbv1[m]>efraim: thanks for the julia update ! <efraim>jbv1[m]: no problem, I just need to finish up the feedback and I can push the last ~58 patches to update all the julia packages <jbv1[m]>for the julia-jll packages, is there a reason why guix does not uses the override setting that exist in the julia package manager instead of patching the binaries ? <itd>civodul: Interesting, thanks! Can R packages depend on another R package of a specific version (range)? (From a quick glance at the repo it looks like "no". I find that surprising.) <efraim>jbv1[m]: "random binaries/libraries" downloaded from the internet don't work with Guix, so we need to use our own binaries so they know what to link against. Also we want to provide our own binaries and not use "magic binaries" provided by someone else. <efraim>by replacing them we get rid of that possibility. Also I don't remember looking at Overrides.toml before <jbv1[m]>I meant that we could use overrides.toml to point the binaries to /gnu/store instead of patching the wrappers <rekado>podiki[m]1: yes, mostly because I wanted to get away from bootstrap 4 and the verbose HTML with so cryptic classes. <rekado>switched to picocss, which is smaller, easier to extend (to me anyway), and with more useful defaults in my opinion <podiki[m]1>looks very modern, I like! and the sidebar hiding/showing on hover is helpful, that could get in the way before <rekado>yes, I liked the idea of the sidebar for quick navigation, but it did get in the way often. The new CSS is a reasonable compromise, I think. <podiki[m]1>QA badges, shiny new look, 1.4.0....quite the end of the year for Guix! <ardumont>finally understood how to pick up my local dev on guix, it was not easy as pie <ardumont>i had to add lots of stuff in there so it's "working" as documented somehow <ardumont>(i had not realized so far how easy i had it when developing the `guix index` tool as an extension) <ardumont>zimoun: jsyk, it's way simpler to dev new extension with the mechanism you push forward <ardumont> ^ so you don't have to delve into the inner guix build cogs <rekado>what new extension mechanism? Is there a new one? <ardumont>you provide an environment variable to where your extension is at <ardumont>and with some right imports, you can extend the guix subcommands <rekado>ardumont: ah, okay, the old one then :) <abhicherath[m]1>heya! I'm using guix on a foreign distro (debian), and after something a bunch of my icons are broken. I narrowed it down to debian's libc being too old for guix's librsvg (from journalctl /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.33' not found (required by /gnu/store/cq4i5h2lnz143y66lfsm3662b9nx13x9-librsvg-2.50.7/lib/librsvg-2.so.2) <abhicherath[m]1>I'm not fully sure how to solve this problem. the first approach I considered was to find and get rid of whatever package I have in my profile with gdk-pixbuf as a propagated input <abhicherath[m]1>but i have like 30-40 packages, and I don't know guile well enough yet to figure out how to check if any of them propagates it <abhicherath[m]1>and I'm not entirely certain that that's the source of the issue anyway <yarl>abhicherath[m]1: After _something_? <abhicherath[m]1>I'm not sure because my system had really long uptime and the issue only started on restart <abhicherath[m]1>I think the correct solution would be some way to tell gnome to keep its eyes away from my .guix-profile <rekado>abhicherath[m]1: this sounds like a problem caused by environment variables <rekado>abhicherath[m]1: normally you shouldn’t have programs from Debian load libraries from Guix (or vice versa) <rekado>often it is environment variables that make applications load libraries that they should not <rekado>my guess is that this is due to XDG_* variables <rekado>you can show them with “env | grep XDG” <abhicherath[m]1>XDG_DATA_DIRS=/home/abhishek/.guix-profile/share:/usr/local/share/:/usr/share/ <rekado>if any of them are set to values pointing to Guix things, consider unsetting them with “unset XDG…” <rekado>and then see if that fixes the immediate problem <abhicherath[m]1>is there anyway to test this stuff without logging out and in btw? I've been doing too much of that ZD <GNUtoo>hi, can I send patches to the mailing list? <GNUtoo>For some reasons debbugs doesn't send me the patch acknoledgement <AwesomeAdam54321>GNUtoo: If it's your first time sending a patch, you have to wait a while for the patch acknowledgement <GNUtoo>It's not and here something looks wrong <GNUtoo>Or is it from when it's received? <GNUtoo>I sent the last mail at guix-patches at the domain: debbugs.gnu.org <GNUtoo>Date: Tue, 20 Dec 2022 21:34:29 +0100 <GNUtoo>and the one before I don't have a copy since I reused it to resend the mail in my mail client. It was a cover letter <rekado>GNUtoo: there are different dates in play. For individual messages it is whatever the Date header says. <GNUtoo>Subject: [RESEND #1] [PATCH v1 0/2] Start adding ZIM file(s) <GNUtoo>So if we suppose that this date is right we can calculate an aproximate latency for the patches received <rekado>some emails come through almost immediately <GNUtoo>like if "patch[PATCH] [WIP] gnu: Add python-3.11." was sent "Wed Dec 21 16:33:24+0100 2022" so it took about 1 hour <GNUtoo>(If there is a moderation then I probably just need to wait for people to look at it then) <nckx>GNUtoo: <How many days should I wait?> One or two. <GNUtoo>nckx: what should I do if the mail don't arrive? <nckx>GNUtoo: Could you be extremely specific? Which mail, arrive where? <GNUtoo>Subject: [RESEND #1] [PATCH v1 0/2] Start adding ZIM file(s) <GNUtoo>Date: Tue, 20 Dec 2022 21:34:29 +0100 <GNUtoo>(1) I didn't get an acknoledgement from debbugs <nckx>I mean, it shouldn't; but there are occasional unfortunate delays. <nckx>I'd wait another day. I'll also ask if there are any known problems. <nckx>I wish I had any. It's a black box as far as we're concerned. <KarlJoad>Is the only way to build an operating-system configuration with Cuirass to build an image of it? There is no equivalent to "guix system build os-config.scm" in Cuirass? <yarl>patched[m]: What do you mean? run emacs inside guix shell? <patched[m]>No, rather to start eshell in a new guix shell from emacs <patched[m]>Different buffers would have different eshell instances with different environments <Guest30>Since eshell's governing process is emacs itself, you would need to run another emacs instance in the guix shell and run eshell inside of that. <Guest30>You might be able to get something working with `buffer-env` [1], I've been meaning to play around with it myself: <GNUtoo>maybe if you manage to change SHELL or something like that it could work, like make a function that somehow changes the SHELL of each eshell <Guest30>GNUtoo: does guix have tooling for setting up an environment in the current shell without executing a subshell? <GNUtoo>what would be neat would be to have the ability for eshell to run commands directly in an interactive way <GNUtoo>like eshell guix shell [...] -- bash <Guest30>yeah, but then you're essentially running regular `shell.el`, since you're interacting with the bash repl instead of eshell <mirai>why does guix not create a overlayfs entry in fstab <mirai>if mount? is #false and the type is one of the %pseudo-file-system-types it just doesn't work as one would expect from reading the 'file-system' 'mount?' entry in the docs <haugh>Anybody doing (shepherd comm) over IP? Can't find anything on a cursory read of the cookbook. <lechner>patched[m] / Guest30 / buffer-env works <nckx>We all do, but I'll let civodul weigh in. <lechner>The comment came from someone who maintains mirrors and an Internet exchange as a hobby, and may or may not help Guix in that department <patched[m]><lechner> "patched / Guest30 / buffer-env..." <- I will check it out <lechner>Hi, after some changes, bug 58658 now belongs into 'staging'. Is it sufficient to retitle as "[PATCH staging]" or is there a better way? Thanks! <lechner>Also, I was conservative with the versions being updated to because the golang ecosystem is developing rapidly and our build system is still at 1.17. Should I reach for the highest possible versions? May I see somewhere if any of the 919 rebuilds fail? If not, how do I run them at home, please? <morganw>Is there a good beginner guide to update (just bumping a package version and testing it) a Guix package on an existing Guix system that has that same package installed? <lechner>morganw / we will help you here. which package, please? <morganw>emacs-org-msg, it has been a version behind for some time <morganw>When I have dabbled with a guix checkout and geiser before I have managed to lockup the machine whilst it tried to compile the checkout. <lechner>morganw / how do you use Guix, please? Are you on a foreign distro, or do you use Guix Home? <morganw>Guix as the OS, pretty much all packages installed through Guix Home. <lechner>great! how do you start Emacs? Do you use EXWM? <morganw>EXWM but no display manager. I'm just starting an X session with `sx`. <lechner>great. that's all very similar to what i have, btw <lechner>except that i never got sx to work. are you using any tricks? <morganw>Only 3 lines in sxrc: xhost +SI:localuser:$USER, setxkbmap gb, exec emacs <lechner>morganw / thanks for that; i will try it later <morganw>I mainly worried about accidentally triggering recompilation. I can run `make` in the checkout in advance and let it run for a while though, if that is what everyone else is doing. But it seems a bit strange to do that when I'm only interested in one package. <lechner>i do not currently use a lot of the Emacs packages that come with Guix. I am trying to decide how to make sure emacs-org-msg is available to your Emacs. maybe we worry about that later. <lechner>what do you mean by "triggering recompilation" please? <civodul>nckx, lechner: changing links to ftpmirror LGTM, please go ahead :-) <lechner>morganw / let's just take the package definition for emacs-org-msg into its own file for now. there is no need to rebuild Guix or anything else <morganw>On the checkout, I think when I switched module within Geiser that was when it locked up. I've used Sly a little, I'm not too familiar with exactly how Geiser works. <lechner>morganw / the integration with the Guix repo only matters once you submit your patch. for testing, let's do something different please <Noob33> someone knows that equipment with more compatible with Guix, as seen in <Noob33> the documentation you need a computer with free drivers within the same <Noob33> computer and the truth I do not know which of the many there is the <lechner>morganw / just copy the (define-public ...) stanza into a file called guix.scm. That file should be located in a convenient place <attila_lendvai>civodul, hi, i think something has changed in shepherd. a call to INVOKE (which calls SYSTEM) that used to work, now doesn't find the executable anymore. i suspect somehow the PATH environment is not propagated somewhere. <morganw>lechner: OK. Bear with me, I just need to get something to eat so I'll probably be back in 15 minutes. <attila_lendvai>i have fixed/avoided it by reimplementing my function in scheme. but some services may go belly up in their start methods <lechner>morganw / no worries. sorry it's taking so long that you got hungry in the meantime. we are full service. please enjoy your meal! <civodul>attila_lendvai: so for now you'll have to find a workaround; in b1aef25453067004279c4267cf25e8d6d365890d i used a wrapper that defines the relevant env var <SUPERB[m]>I was wondering if it’s available to use Guix package manager and its abilities like rollback for rolling distros like Arch to avoid breaking? <civodul>d'oh! i should take another look, sorry about that :-/ <attila_lendvai>civodul, if you do you can ignore the convoluted history of that issue, and only look at the last patch. also note that it's once again dated, shepherd moved on another release <morganw>lechner: I've copied the define-public form for the package into a file called guix.scm. Presumably I need to update the commit reference and the version number? <attila_lendvai>the reason is that if it'll get in quickly, then i don't need to duplicate the change in my channel, which is not easy because of how the macro-level stuff and packages interact. i need to copy the whole machinery, not just the changed macros. <attila_lendvai>if it's not probable to get in fast, then i'll need to think about how to proceed <lechner>morganw / yes! to avoid confusion at this this stage, i also recommend to prefix the variable (but not the "name" field) with "my-". please also enter the name of that variable starting with my- at the end, so the file evaluates to it <lechner>morganw / then you can run guix build -f guix.scm insert the "actual hash" from the error message into the appropriate place in your file, and run the build command again <morganw>It is suggesting I need to add (use-modules (guix packages)) on the first invocation. Should I add it? <lechner>yes. you will actually need a bunch of those to cover all the prerequisites, as well. sorry <lechner>nckx / should i prepare a merge request? I'd like to appear proactive <jas4711[m]>hi guix! i'm looking for some help packaging a new perl module. i've written a package description that works with 'guix build' but I had to use (arguments `(#:tests? #f)) to make it build. if I remove that, the 'make test' phase fails because it can't find the newly built perl module (I think). Ideas? The guix package definition is here: https://gitlab.com/-/snippets/2475459 <lechner>jas4711[m] / will you please post the error? <jas4711[m]>the error message i get is this: t/test.t .. Failed to load PCSC library at /mnt/jas/src/pcsc-perl-1.4.14/Card/../blib/lib/Chipcard/PCSC.pm line 247. <jas4711[m]>i'm not sure what it is searching for, maybe the perl module or the shared library? <nckx>Oh, no need, thanks. It's just a simple change. <lechner>nckx / how long does that take to become live, please? <nckx>It used to be regenerated hourly. <nckx>No, I just mean I haven't checked again. Thereabouts. If it's not up by tomorrow, something's stuck. <jas4711[m]>re perl-pcsc: the package builds some C code that tries to load the libpcsc shared library I think. So this is probably a search path issue <lechner>jas4711[m] / yeah, those are a common issue <morganw>lechner: the package is now built with the updated hash <lechner>morganw / okay, congratulation! you graduated from the package builder class. now the challenge is to make that package available to your emacs <jas4711[m]>lechner: yes, I found it is a dlopen call that fails. is there some other perl package that has this? i'll try to find one to look at <nckx>I got one ‘invalid’ TLS certificate whilst testing. I wasn't running verbosely, so I didn't see which server. It was almost certainly because I pick my own roots, but let's keep an ear out for any reports of ‘failed downloads’ in the coming days. <lechner>jas4711[m] / does the call use an absolute path, or does it rely on LD_LIBRARY_PATH being set elsewhere in the build system? <jas4711[m]>lechner: define LOAD_LIB() dlopen("libpcsclite.so.1", RTLD_LAZY) <lechner>morganw / my top choice would probably be to reconfigure your home environment to use your updated package. the reason is that you rely on Emacs so early on and cannot easily use 'guix shell' to bracket the invocation <lechner>jas4711[m] / are you doing this inside a guix shell that makes the library available? <lechner>morganw / you can do this by cutting and pasting your update package definition into your home.scm. just install the package together with the others. i do not use the ->specification mechanism and refer to the variables instead. how is your file set up, please?/ <efraim>jas4711[m]: we normally add the package as an input and patch the dlopen to give it the full path so we don't have to rely on pcsc-lite being installed somewhere <jas4711[m]>lechner: i tried 'guix shell pcsc-lite -- guix build -f security-token.scm' but same error. <jas4711[m]>efraim: do you have a pointer to some other perl package that does this? <lechner>jas4711[m] / efraim may be better positioned to help you from here, especially because i have to bolt soon <efraim>jas4711[m]: perl itself, with /bin/pwd <jas4711[m]>efraim: thanks! i found it and will try to learn how it works <morganw>lechner: I've just got a list of strings for package names, following (map (compose list specification->package+output)... <lechner>morganw / yeah, i think you may have to append my-... to the list created by 'map', but i'm not sure <morganw>I can try to start a new emacs instance inside emacs after updating the home configuration. Do you think that is feasible? <lechner>morganw / you may be more experienced with Emacs than I. that sort of thing has not worked out well for me in the past. i personally might start Emacs in a text terminal instead, i.e. without 'sx' except I would to so inside a guix shell -f guix.scm <lilyp>note that guix home also supports --container, so you can start an emacs from there too :) <lechner>lilyp / i never had an issue starting them, but they always do too much (like log into IRC again) and i find them hard to quit <lechner>ESC works, i think, but C-c C-x never gets to the child <morganw>In the inner emacs the package is loaded and appears to be working. Is the patch just the commit hash, version, and file hash changes? Is there anything else I would have to test? <lechner>morganw / and thanks for your contributions! <lilyp>cursed question: are we allowed to invoke emacs in a snippet? <lilyp>VesselWave: I'm pretty sure it's just libGL.so and ships with mesa <VesselWave>lilyp: I get `ld -l OpenGL` failed building hyprland (my package definition) <lilyp>which build system are you using? cmake or meson? <Hush93>How to connect the guix channel in Weechat but it works, I have tried and I do not get accurate results <lilyp>okay solution 1, try meson :) <Guest30>VesselWave: libOpenGl.so.0 isn't shipped with mesa, add libglvnd to your inputs <VesselWave>Guest30: Thanks a lot! Are you the same Guest30 that answered me yesterday? <Guest30>yeah, I really need to get my libera config set back up lol <lilyp>only for looking at derivations, sadly <johnabs[m]>I'm getting a strange error that I don't think should be happening: "No such file or directory, guix-popup", but I have magit and such installed <Guest30>johnabs[m]: what versions of emacs and emacs-guix are you using? <johnabs[m]>Guest30: emacs 28.1 and emacs-guix version 0.5.2-6.cf5b7a4 <johnabs[m]>Also, I have the whole "(add-to-list 'load path ".guix/profile") stuff, and the (guix-emacs-autoload-packages)" at the top of my config file <Guest30>what codepath gives you that error (any particular emacs-guix functions, etc.)? <houseHush>How to configure the terminal Weechat client, to receive messages from the Guix channel in the terminal, I have tried with the documentation, it did not manage to make it work for me <johnabs[m]>Guest30: Basically any attempt to run M-x guix or guix-help, or anything <Guest30>if you `C-h f ` for guix-profile-popup, does the help page have its info? <Guest30>and to confirm, you've restarted emacs since you installed emacs-guix, right? <nckx>HouseHush: This is beyond the scope of #guix, but: <nckx>/server add libera irc.libera.chat/6697 -ssl <nckx>You can then use the F5 (up) & F6 (down) keys to switch tabs. <nckx>I'm sure that was well received & understood. <johnabs[m]>Guest30: No, it does not. And yeah, I restarted emacs, and even ran pkill to make sure no daemon process was running. Interestingly, certain things show up in `C-h f ` for guix, such as guix-about, but when I press enter, I get the same "No such file or directory" error for guix-about. Do you think I need to use (use-package! (or require) guix-emacs) in my config as well? <Guest30>what does a run of this guy spit out: <Guest30>`echo $EMACSLOADPATH | tr ':' ' ' | xargs ls -la | grep guix` <johnabs[m]>Guest30: lrwxrwxrwx 1 root root 113 Dec 31 1969 guix-0.5.2-6.cf5b7a4 -> /gnu/store/03mf1n8vrf2q50rv5vd2ijgc45bpg6s4-emacs-guix-0.5.2-6.cf5b7a4/share/emacs/site-lisp/guix-0.5.2-6.cf5b7a4 <johnabs[m]>lrwxrwxrwx 1 root root 90 Dec 31 1969 guix-emacs.el -> /gnu/store/8mnxqvh60bswiy8qdwl67z6h8py3hjac-emacs-28.1/share/emacs/site-lisp/guix-emacs.el <johnabs[m]>lrwxrwxrwx 1 root root 91 Dec 31 1969 guix-emacs.elc -> /gnu/store/8mnxqvh60bswiy8qdwl67z6h8py3hjac-emacs-28.1/share/emacs/site-lisp/guix-emacs.elc <Guest30>probably should have been but 3 lines isn't too bad on spam :-) <johnabs[m]>Oh okay, good :) (Also, did it not show up as 3 separate lines? It looks like that on my end, but i'm using element to connect to the IRC channel, which may be doing some weird stuff with formatting) <johnabs[m]>(Oh, or did you mean use Enter, rather than Shift-Enter, so it showed up as 3 separate messages?) <Guest30>nah your 3 lines came through separately, you're good <johnabs[m]>Hmm, similar bug now that I've installed emacs-cider, actually <Guest30>johnabs[m]: anything weird going on in your init.el? <Guest30>only difference between our machines is I'm running Emacs 29 <johnabs[m]>Guest30: Actually, I think I may have found the issue, but we'll see. I'm using doom emacs, and I found a bug when trying to sync, which may be interfering with my other packages, give me a hot second to try to fix that, and I'll be back xD <Guest30>doom emacs certainly changes things lol <Guest30>there's a lot of custom module loading that goes on in there, did you package it yourself for guix? <johnabs[m]>Yes, yes it does xD Apparently mu4e is crapping the bed, and causing some issues :/ <johnabs[m]>And no, I wish I was that comfortable with guix to do that, I'm still learning lol <johnabs[m]>Thanks for your help! Having confidence that I was the one who screwed it up helped me find the error lol <Guest30>best of luck lol, i'd probably recommend starting with vanilla emacs for your own sanity, but power to you if you can get doom working straight away! <Guest30>consider submitting a guix patch if you end up building a derivation for doom as well, best of luck! <johnabs[m]>I got the whole thing! I just didn't package it and le gasp installed it manually. Guix-heresy, I know, but I'm still a noob lol <johnabs[m]>And will do! Though for now, I'm trying to tackle zotero...then doom can come next lol <Guest30>might be worth looking into containerized solutions <paul_j>Evening all! Is there anything I should be aware of when it comes to installing quicklisp on guix? I have installed it as I would on other distos, and allowed the .sbclrc to be modified to initialise it each time. When I use sbcl from the command line, it works, but in my (functioning on other systems) stumpwm config it is saying "package QL does not exist" during the initialisation <paul_j>I can't see quicklisp as a package available in guix directly, although there are other packages used for processing the download stats. <lechner>paul_j / your stumpwm may not have the QL package as an "input" <lechner>the packages that do work may not be same ones that are installed in your profile, i.e. they could be different store paths <paul_j>lechner: do you mean when I install stumpwm? <lechner>yeah, Guix is different from most other operating systems <paul_j>It is currently in a list of packages installed in the base profile <paul_j>...used for "guix system reconfigure" <lechner>yeah, they may not see each other's prerequisites. all of them are tied down to the versions with which the packages were built, and no other <paul_j>How do I make quicklisp and input for it? I didn't do anything specific for sbcl (installed at the same time as stumpwm), apart from the usual install of quicklisp in my user profile, and that works as expected. <lechner>the sbcl in your user profile and the one used by stump is not necessarily the same. even if it is, not all installed modules may be visible from each. multiple versions of all those things may be installed. they are only accessible via their absolute path, via symbolic links in your profile, or via some special environment variables (such as $PATH) <lechner>well, i went to college and should be better with plurals and such <paul_j>It's quite understandable to me :) <lechner>i was trying to eat a cookie and type at the same time <paul_j>So I understand the basic structure of guix and the way it links files, but I am surprised that there may more than one version of sbcl installed. I am not currently using any manifest, and install everything for the system in one file. Therefore everything is updated at the same time, and *should* be consistent (IMHO!) <paul_j>I have had guix on a laptop for around 12 months. My aim is to make this my primary laptop, so I can stop using gentoo on my other laptop. I have gentoo on my desktop, and will consider changing that as well in the future, but I need to have a better grasp of how guix works before I make that step. <paul_j>"which sbcl" gives: /run/current-system/profile/bin/sbcl <paul_j>which stumpwm gives: /run/current-system/profile/bin/stumpwm <lechner>paul_j / cool, i switched cold turkey in April after two decades on another distro <paul_j>/run/current-system/profile/bin/stumpwm -> /gnu/store/myxynisynhnan4d6vk6zb57yy21c7s9q-stumpwm-22.05-1.ff6cb73/bin/stumpwm <paul_j>/run/current-system/profile/bin/sbcl -> /gnu/store/bjj3ny87yckv1y5ys2cld0sy4sp9nfm0-sbcl-2.2.11/bin/sbcl <lechner>or if that yields too many modules ls -ald /gnu/store/*-sbcl-*/bin/sbcl <paul_j>As I said, I get that these are in the store, but I don't get that the sbcl version used by stumpwm may be different from that invoked in a terminal since I update them all at the same time currently. If I was using manifests, and updated these at different times I can agree. I guess I am back at my original question, since even if I have different versions of sbcl being invoked, I still have one .sbclrc and one quicklisp install in my <paul_j>home directory, so everything should work as expected with stumpwm. Hence my original question about the best way to install quicklisp in guix, since it isn't currently a guix package (as far as I can tell). <lechner>sorry, i cannot help you with quicklisp, and you are likely correct that your sbcl versions are the same <paul_j>Or, should I not be using quicklisp, but installing the packages directly through guix. Similar to avoiding use-package in emacs for installing packages, installing them directly instead. <paul_j> I had better go and check the cookbook - there might be more in there... <lechner>you may be able do to either, but it may be hard to mix the installations. i personally prefer official packages when possible. i even package and maintain my own stuff, which is trivial in Guix. In never run sudo curl | bash but will work with cabal or npm for a little while when needed <paul_j>I'm quite happy to do it "the guix way" - just sometimes you need to dig to find what that way actually is :). I packaged my own configuration of dwm in a personal channel, and like very much the approach. I am hoping to get enough free time this holiday period to finally get the laptop in a fully usable state, and then make use of it in the new year. <paul_j>Anyway - I need to go and walk the dog! Thanks for your help lechner - I'll catch you round again, I'm sure! <civodul>vagrantc: from a quick test (GUIX_DAEMON_SOCKET + 'guix copy'), the guile-ssh upgrade looks good! <vagrantc>civodul: thanks! will probably wait till tomorrow, unless someone else wants to push <vagrantc>this is my first time looking at the QA stuff ... pretty nice :) <vagrantc>civodul: and perhaps comment on the bug for propriety :) <morganw>Just to check, if I've emailed guix-patches@ for the first time will my mail need to be manually released if I'm not subscribed to the mailing list? <lechner>Hi, i think it will end up as a new bug without approval, but i am not sure. did you receive an automated reply? <nckx>morganw: Partially. But no mails are pending (yet). <morganw>I sent the mail (maybe an hour ago) and didn't get a bounce message, but I can't see it in the mailman web interface. <nckx>‘Things do seem to be running more slowly however. I am seeing some larger Mailman queues.’ (Yesterday—but that's not that long ago from today.) <nckx>You're also the second person to bring it up today, so it's likely things are clogged again. <morganw>It isn't urgent so I'll give it a couple of days. Thanks for checking. <mirai>morganw: it took me ~9h before my mail went through <nckx>Early holiday debauchery at the FSF offices. <nckx>…now there's an image I unconditionally apologise for conjuring up. <nckx>mirai: I was just answering you.