IRC channel logs
2023-06-23.log
back to list of logs
<Kolev>Reinstalling. Still struggling with rde. <whereiseveryone>razlix77[m]: TLDR: meow is like helix/kakoune but implemented in Emacs Lisp and faster than evil <VesselWave>Do you know what font I should install on guix system to display symbols at the end of toys.whereis.みんな ? <whereiseveryone>In the past I used some other package to get the appropriate fonts which I can't remember now <Kolev>whereiseveryone: I'm still having issues with paritioning and file system definition in rde <xelxebar>I think the ibus-anthy package might be broken. Starting ibus-anthy-setup complains about the engine xml file not being found under /usr/local/share, and the paths defined in share/ibus-anthy/setup/_config.py all sit under /usr/local. <xelxebar>I probably won't be able to get to it any time soon. Leaving it to you guys! <the_tubular>I want to use guix to download lists, is there a link I could get to have an idea on how to do this ? <the_tubular>And probably put them somewhere outside the store if possible <sozuba>`guix package --search-paths -p "/root/.guix-profile", I am trying to understand the syntax. <sozuba> Without the option '-p' / --profile it would only repo <sozuba> │rt the environmental variable for that profile right? Only the -p option sets the profile to be loaded. <sozuba>also is this the same as source /root/.guix-profile? <tao[m]1>I didn't include a subject line, unsure if that was necessary <HiltonChain[m]>idk if that's a moderator approval but you need to wait some time (hours?) when posting to the mailing list for the first time. <hwpplayer1>how much megabyte/gigabyte do I need to update and upgrade system each time for GNU Guix ? I ask that because I have a limited connection. <HiltonChain[m]>That depends on which packages are in your system definition and how many packages have been changed for the upgrade... <davidl> juliana[m]: I found my error now. The blog post I followed didn't mention a thing which of course is necessary: that when you put the guix.scm file in .guix/modules/mypkg-package.scm you need to edit both the vcs-file? procedure and the line with local-file "dirpath" - I had forgot to edit the vcs-file? procedure. To answer your question to me: no the bash-coding-utils-checkout is not an existing directory. It's just the name argument to the <cdo256>Hi all. I've been having trouble getting FIDO working with my yubikey on guix system. It works fine on my debian machine, but on Guix, it doesn't detect any security tokens in Firefox or Chromium. I'm running the latest Guix. I couldn't see anything in the browser logs. It is appearing in the system logs and the right dev entries are appearing I think. I've ran pcsc-spy and it appears to be the same between guix and debian. I' <cdo256>strace but chromium forks itself before I can see what's happening. This leaves me a bit stumped. pcscd is running. My system.scm is: https://0x0.st/HQPM.scm. I don't think I'm doing anything particularly fancy there. <HiltonChain[m]>You can add a service like this and add your self to the "plugdev" group. <rekado>I’m using a Yubikey on Guix System <rekado>I had to add the pcscd service to the list of system services <HiltonChain[m]>hmmmm pcscd seems to be related to Smartcard functions, maybe it's not needed for FIDO <cdo256>the udev rule + adding myself to plugdev did it! Thank you!! <apteryx>rekado: I use yubikey without the fscd service, just the udev rule is enough <apteryx>I think I detailed how to setup a yubikey in the Cookbook <apteryx>cdegroot: for reference, it's documented in 'info "(guix-cookbook) Using security keys"' <apteryx>cdegroot: apologies, this was for cdo256 ^ <sozuba>I am at the initial phase of installation, i read that after i invoke 'herd start cow-store /mnt', all packages added to /gnu/store during installation are written to target disk (whats mounted on /mnt), does manual package installation gets added to the target disk as well? For example i want to install vim on live usb, so after i start cow-store, will it only get added to the target disk and not on <ds-ac>sozuba: If you are running 'herd start cow-store /mnt', I assume that you are not using the graphical installer. Is this correct ? <nckx>sozuba: ‘written to target disk’ means written to a temporary directory on /mnt, so your / in RAM doesn't fill up and die. They are *not* written to /mnt/gnu/store, so it does not mean that some packages will be present once you reboot into the installed system. Only the closure of your system.scm will be in the new store. <nckx>If you ‘guix install vim’ in the live installation environment, it will be gone once you reboot. cow-store is a pragmatic hack, not an installation strategy. <ds-ac>sozuba: Note that if you want a package installed on the target system upon installation, you should probably edit the scheme configuration file of the new system before running guix system init. Is this what you want ? <sozuba>nckx: Thank you very much, it is much clear now :) <nckx>Oh good, I wasn't sure :) <sozuba>ds-ac: thanks for the response.And no that wasn;tmy question, nckx answered it though :) <nckx>Whether my ramblings were of any use. <nckx>ACTION still trying to debug error: failed to load '/gnu/store/…-profile/share/guile/site/3.0/git.scm': Function not implemented <nckx>mirai: I can push the mympd update later today (assuming I get Guix updated into 2023 :) <nckx>I'm not sure what to think of it. <mirai>there's really no reason to allow it tbh <mirai>supposing said CGI backend calls curl or wget behind the scenes, you just made your backend route some requests through evilserver.tld <nckx>Yes. My concern is not with that or your fix or your code, it's pushing ‘random’ ad hoc fixes like this into distro boilerplate code. <nckx>That, and being triggered by ‘if’ 😉 <mirai>nckx: my bad, I assumed your answer had an implicit 'should we allow HTTP_PROXY to be set by the clients?' <mirai>I don't think we (nginx?) have much choice here, since its due to the convention of prefixing fastcgi params with HTTP_ <nckx>I'm with you on that one. <nckx>nginx treats different HTTP headers differently in many places, at least by default, so it wouldn't be unprecedented for them to disallow HTTP_PROXY by default. But I haven't deployed enough real-world CGI applications to know if I'm being naive. ☺ <nckx>I'm not against mitigating ancient security flaws at the distro level but it is the worst level. <nckx>OK, both patches LGTM, and I'll push them later. <mirai>I'm amending the docs and could use some guidance regarding this sentence: “… returns a G-expression (see G-Expressions), which should, once serialized to the disk, return a string.” <mirai>are G-Expressions __serialized__ to the disk? <mirai>doesn't seem to be the right terminology here <rdrg109>[Q] How to list all timezones that are known to the system? In Arch Linux, I could do it by executing $ timedatectl list-timezones <mpaint>I'm on debian which has GTK 4.8. Is it possible to install GTK 4.10 from guix and have the applications use the guix version instead of the system version? Would changing a system variable do the trick? <mpaint>Oh dear, even guix is still on 4.8. <rekado>mpaint: see the gnome-team branch. That’s on 4.10.3. <rekado>jlicht: hey, I’m currently facing a bizarre problem with the node-build-system. Do you have a few minutes to discuss this? <rekado>it’s difficult to debug because I can only reproduce this on our cluster installation of Guix but not on my laptop. <rekado>the problem is that *some* of the files of at least one node package are not copied to /lib/node_modules/<pkg>/node_modules/<bad> <jlicht>rekado: Of course! Let me have a peek <jlicht>rekado: do you happen to have a public package expression/channel as well? <rekado>I picked node-chain-able as an example because some of its files don’t appear in the output of node-fliplog-0.3.13 <rekado>the diff I pasted above shows the output of node-fuse-box, which has node-fliplog (but not node-chain-able) as an input <rekado>I haven’t been able to reproduce this behavior on my laptop <rekado>I don’t know how npm decides what files to copy to the target package’s node_modules sub-directory <jlicht>rekado: on current master, it should just copy over everything <rekado>as far as I can tell there’s nothing terribly unusual about how Guix is deployed on the cluster. /gnu is a local file system (which happens to be exported over NFS for other nodes) and /tmp is just a regular disk-backed location. <rekado>I can’t think of anything that would justify the difference in behavior between the two systems <rekado>the derivations are exactly the same. <jlicht>rekado: at the risk of asking the obvious, I assume you've tried rebuilding the derivations (e.g. with --check)? <rekado>the build for node-fuse-box differed by one file. <rekado>one additional file was missing in the repeated build <jlicht>oh wow, that is somehow even worse than I imagined <jlicht>on the laptop it consistently has everything? <rekado>I added a post-install phase to node-fliplog to explicitly copy the files from node-chain-able, but that had no effect on node-fuse-box that has node-fliplog as an input (and not node-chain-able). <rekado>i.e. even when node-fliplog *has* the missing files of node-chain-able packages *using* node-fliplog don’t have these files <rekado>it looks deliberate, as if there’s a file that selects what files to copy <rekado>(and perhaps due to some weird file system sorting issue that file is respected only on this one system but not on my laptop) <jlicht>rekado: the one thing that could make it bring over less would be the "files" entry in package.json of the dependency, but I don't directly see how that could lead to different behaviour on different systems <jlicht>even less how that could lead to different results each run <jlicht>let me jump into the relevant bits of npm <jlicht>rekado: You could add a `npm ls` phase (after the configure phase) and see if the two builds have the same output there <sughosha>Hi all, I would like to package some free wallpapers to Guix, with new wallpapers.scm. Would it be fine? <jlicht>rekado: that'd be `npm ls --install-links=true` btw, otherwise it gets kind of unhappy either way <stikonas>sughosha: not sure if those would qualify in terms of legal license <sughosha>As per this example, the license is cc-by4.0 which is already in guix/licenses.scm. <jlicht>rekado: but I'm seeing some weird things going on, looking at the node_modules/chain-able/package.json file in the fuse-box install dir <stikonas>sughosha: it's a bit legaly unclear at the moment whether you can assign cc-by4.0 as the model is trained on non-free data <stikonas>and probably training program is also not available/non-free <sughosha>stikonas: Sorry, I didn't get what you mean by training program. As wallpapers, only the .jpg images matter, right? The repository has only images and no code. <reed42>Am I correct in assuming that if guix spends a long time doing <reed42>building /gnu/store/blahblahblah.drv <reed42>that it did not find a prebuilt version from a substitute server? <jlicht>rekado: you could even try `cd $(guix build node-fuse-box)/lib/node_modules/fuse-box; npm ls --install-links=true` on both systems <stikonas>as those are AI generated images, it's somewhat similar to binary only program <stikonas>though with AI there is somethin in the middle too that Deban calls "toxic candy" when model program is free but training data is not <stikonas>anyway, I'm just a user here, perhaps somebody else can clarify <jlicht>rekado: w.r.t. your node-fliplog adventures; node 'hoists' dependencies to highest level possible, and it may (or may not) re-link them in. That is, it uses the original store path, not your modified chain-able-in-fliplog. <jlicht>put another way; it looks at package.json files, not at (nested) levels of `node_modules` <sozuba>I amdoing the manual install and so i copied the desktop.scm to /mn/etc/desktop.scm. When i try to edit it, it says "read only". Is this expected or did i do something wrong. And yes, I know how to override it.I just want to know if this is normal or not. Thanks :) <jlicht>rekado: we could probably convince our node-build-system to do something else, but we are already veering off the supported use-cases. (The actually extremely helpful folks who work on npm don't seem to care much for distro packaging woes) <sozuba>HiltonChain[m]: yup. But i wanted to know if the "read only" aspect is expected? <sozuba>HiltonChain[m]: got it. Thank you :) <bdju>is nestopia-ue the best NES emulator guix has? <sozuba>any examples of a luks -> lvm (swap,root,home) config? root and home on ext4. <sozuba>i searched online, the ones i found is a bit confusing <sozuba>sorry if i messed up with my directional layout, i thought that would be easy way of explaning.Guess i am wrong :D <HiltonChain[m]>I think it's to add a list of mapped-device (luks first, lvm second) to the mapped-devices field of operating-system <HiltonChain[m]>then in file-systems, set relevant file-system instances' dependencies field to mapped-devices. <sozuba>HiltonChain[m]: yes, but i am a bit confused with respect to naming in source and target. for LUKS and LVM with three fulme groups. That's why i was wonderingn if there is an example concifg around, as i am sure i might not be the first to choose this layout :) <sozuba>For example, (source (uuid "1234567890")) and (target "guix") <sozuba>the uuid is the lusk source will be used from uuid mentioned in -> '/dev/sda2: UUID="b11a3767-a8ff-4c94-b7c1-8900b779f9df" TYPE="crypto_LUKS" PARTLABEL="Linux LUKS" PARTUUID="d0b37d84-1cd8-4929-aeea-dd90f5e8b1e2" ' <sozuba>and the target is used was the name i give for unlocking, like 'cryptsetup luksOpen /dev/sda2 guix' <sozuba>i amnot sure if i am doing the right thing <sozuba>that;s why i was looking for a reference <janneke>jpoiret, civodul: headsup; i've reset hurd-team and finally got a 'guix pull' to finish <HiltonChain[m]><sozuba> "and the target is used was the..." <- Yes, that's how Guix do it. <HiltonChain[m]>sozuba: for LVM, it's doing "lvm vgchange --activate ay <source> && lvm vgscan --mknodes", then checks for "/dev/mapper/<each target in targets>" <sozuba>HiltonChain[m]: ah okay, tat makes sense.Thanks again :) <mirai>The idea is to make it easier to modify the documentation as changes come <rekado>jlicht: thanks for confirming that it does in fact read package.json from the original package and doesn’t just grab lib/node_modules/<a>/node_modules/<b> for the following packages <rekado>so the question remains whether there’s something ambiguous or sort order dependent in chain-able’s package.json that can lead to this difference in behavior <rekado>as the diff shows it’s chain-able, fast-deep-equal, lodash, regenerate-unicode-properties, and uri-js <rekado>files for *all* these packages end up missing when building the node-fuse-box derivation on this machine <jlicht>rekado: so it only happens to transitive deps, right? <rekado>node-chain-able is an input to node-fliplog, and fliplog’s node_modules/fliplog/node_modules/chain-able directory does not contain all files <jlicht>rekado: so fliplog's node_modules/fliplog/node_modules/chain-able is the same/similar to fuse-box's node_modules/fuse-box/node_modules/chain-able ? <jlicht>(as long as you don't modify it manually in fliplog's phases) <jlicht>rekado: I've just confirmed that it simply relinks from the original package. What surprises me that this ever worked (/w guix), as those transitive deps may not be available to the build environment in the first place <rekado>yes, fliplog’s chain-able directory is similar to fuse-box’s <jlicht>rekado: Have you excluded npm /w your operational environment from being an issue? <jlicht>(assumming that's the path of your chain-able@1 in /gnu/store) <rekado>this results in the same broken node_modules directory <rekado>jlicht: I’ll run it under strace to see what it touches <jlicht>rekado: just to exclude more stuff, you could copy the /gnu/store<>chain-able/lib/node_modules/chain-able to /tmp/chain-able, and see if changing the pasted package.json to refer to that path actually works or not <lilyp>mirai: s/A clause/Each clause/ makes no substantial difference, keep the current wording <sozuba>HiltonChain[m]: Hey thanks, no worries. good night :) <lilyp>I think you should unpack the definition iteratively, as you see done when languages get described in BNF <lilyp>i.e. (@var{field-name} @var{type-decl} @var{documentation} @var{option}*) <lilyp>@var{type-decl} is either @var{type} or (@var{type} @var{default}) <lilyp>@option is one of (serializer @var{serialier}) or (sanitizer @var{sanitizer}) <rekado>jlicht: I see the same behavior when referring to /tmp/chain-able (where I placed a copy of the store dir) <jlicht>rekado: and just to exclude the obvious, /tmp/chain-able does actually contain these files? You can open them etc and everything? <rekado>e.g. /tmp/chain-able/dist/Chainable.all.js exists, and I can open it <jlicht>is the package.json I pasted also located somewhere in /tmp? Some cross-fs shenanigans are the last big thing I can think of <jlicht>But yes, at this point I'd go for a strace and trying to see what it does different from the working system <jlicht>I'm off for the evening, good luck and please let me know what you find! <rekado>when doing this on /tmp there’s no difference <rekado>I’ll read through the strace output and see if there’s something interesting <sozuba>Its a LVM on LUKS partition scheme <lispmacs[work]>is there some difference in Guix between distro maintainers and reviewers? Is the review process layed out some where? Can I help with review process on my own package I submitted? <sozuba>what is the command to shutdown guix from terminal. I know reboot works, but is there a poweroff command? I amin the live installation image <mekeor[m]>@sozuba i use "loginctl poweroff" from elogind system service <lilyp>lispmacs[work]: anyone can review a patch, it's mostly to make sure that the guidelines in section 22 are followed <lilyp>few people are committers (allowed to sign off patches and push them to a branch) <lilyp>even fewer are maintainers (responsible for long-term vision and planning) <Noisytoot>What's the last commit with a working igt-gpu-tools package? <geno>is there any way to automate packaging software updates? right now it seems like packages get updated when someone cares enough to make a patch. it can't stay like this forever, right? i don't want to manually modify package definitions all the time to get the latest security updates <rekado>geno: I regularly upgrade all CRAN and Biocoductor packages. <rekado>these are bulk upgrades, and I use the excellent “guix refresh -t {cran,bioconductor} -u” for this <rekado>the better our importers the better “guix refresh” <geno>I'm thinking for example of i2pd which allows to enter an anonymous network but the guix version is from last november so i won't install that <geno>rekado: thank you for upgrading those packages <juliana[m]>the simple fact of the matter is that there aren't enough people working on Guix to keep all the packages up-to-date. if you wanna dig in and help out it would be much appreciated :3 <geno>i will see what i can do <Guest28>I wonder, does Guix have something to be aware that packages are required to be bumped because of security issues? Sometimes I see commits and wonder if they just know that because they work in it security or something and is therefore aware of it. <nckx>Some people keep an eye on the CVE feed, and ‘guix lint’ queries it, but I suspect the latter doesn't have that great an effect. <nckx>‘Mah butt’ seemed a bit rude. <nckx>I'm subscribed to a fair number of ’foo-announce’ type lists & release RSS feeds, which also call out security releases. <nckx>(Y'know, back when I still updated things.) <Guest28>I guess normally this is done automatically as of maintainers get a notification. Can't image that Debian with it's thousands of packages have manually subscribed to each package for security updates or am I mistaken? <mirai>nckx: flac is one of those dependencies that would benefit from an update (there's some CVEs on it) <mirai>geno: I'm afraid that not every package can be automatically updated <mirai>quite a few have patches or custom stages <mirai>some packages undergo dependency changes (addition/removal) <nckx>Noisytoot: Did you try 90c8f623? It predates a recent procps update which seems to be to blame. <nckx>NixOS automates routine version bumps, which are a significant part if not a majority of all updates. <mirai>in the past I've encountered some package definitions with “outdated” patching snippets or over/under-specifying dependencies <mirai>IMO automatic updates could be doable for a subset of packages <mirai>provided they come with a working test suite <nckx>It's true that I often take another look at a routine 2-line update just to see whether something might be dropped. A bleary-eyed human approving bot-generated updates might not. Might still be worth the trade-off. <mirai>otherwise it's quite possible that we'd end up with 'install this update for a bleeding edge broken package' <mirai>hardly an upgrade worth getting excited for <nckx>You mean you don't ‘guix pull’ to receive your weekly assignment of new bugs to fix? <Guest28>If I reboot a system and it hangs as off shepherd shuts service down but the device never actually reboots or does a power off, how would I debug this and find the cause for it? <bjc>Guest28: i don't have an answer for you, but are you mounting something over the network? <mirai>I do get them, just via git pull while I'm working on something unrelated <mirai>maybe I should set 'yak' as an alias for git <rubin55>hi all, new to guix! installed guix system in a kvm vm, virtio disks, gpu, ethernet, all working nicely. did an upgrade too and installed some packages (chatting through irssi atm) <rubin55>I created a .config/monitors.xml (gnome) with native resolution, that I would like to add to the gdm user (i.e., in /var/lib/gdm/.config/monitors.xml); what is the right way to do that (doing that as one would do it on a non-declarative system results in disappearance of the file on reboot) <lispmacs[work]>rubin55: I'm not an expert on that, but I would look at §12.9.6 (X Window) in the manual <nckx>Noisytoot: It built for me.