<muradm> minikN: sway runs dbus daemon it self as far as i know <muradm>you don't have to start it separately <minikN>Then why isnt DBUS_SESSION_BUS_ADDRESS available? Hmm.. <muradm>if it does not stated before sway <muradm>also where do you start blueman-applet? <minikN>Unfortunately not. If I try to use debian paste it errors with "do not spam". Something in the code it doesn't like. <muradm>there are many of them, but pastebin.com is blocked in my location :D <muradm>may be xwayland is missing or DISPLAY vardir? <lfam>Got a rough draft of paremeterized revisions of kernel deblobbing without affecting the linux-libre-headers-5.4.20 derivation 🙏 <roptat>still trying to build adb with my soong-build-system. I managed to build one of the java dependencies, but the second dependency is missing some implicit package it seems, because it can't find android.util.Log :/ <iskarian>sneek, later tell maximed: maybe try guix lint -c derivation to run a bunch at once? <minikN>What can I do when I get `guix system: error: error parsing derivation `/gnu/store/601frv73iipm2qj39gi39zpdzyhz25lj-activate-service.scm.drv': expected string `Derive(['` running `guix system reconfigure`? <lfam>What command did you run to get that error minikN? <lfam>And are you testing any changes, or are you "only" using Guix? <roptat>gah, looks like adb depends on the whole android sdk :/ <minikN>lfam: I changed something in my sys config, rebooted, got an error message saying the boot process terminated. I changed back to last generation in grub menu, reverted my changes in the config, ran guix system reconfigure, this error appears <minikN>muradm: btw, bricewge was right, launch sway with `dbus-launch` fixed the issue. <lfam>I haven't seen that kind of error before but maybe someone else is familiar with it <nckx>minikN: IME that error always means file system corruption. <lfam>To clarify, you finally ran `guix system reconfigure` with any unchanged config, so you'd expect nothing to change? Maybe modulo having run `guix pull` since the previous reconfiguration <lfam>I was worried about that kind of thing nckx <nckx>My guess is that that .drv file will be empty if you look at it. <lfam>Either that or miscompilation <nckx>OK, that would be worse 😛 <minikN>Yeah the file is corrupted. I knew that already, because this is the third time this is happening. I read online that this is caused by ext4 fs and should not happen with btrfs, so I switched to btrfs. Happens again. <lfam>I don't think it's caused by either ext4 or btrfs. Both are mature, although ext4 is extra-mature <lfam>It's more likely that it's caused by either 1) bad RAM 2) bad storage controller 3) bug in Guile <lfam>Not in any particular order <lfam>I wonder what is the easiest way to narrow it down <minikN>More important to me, Is there any way to fix it that doesn't involve.... reinstalling the system? <lfam>Well, if the problem is with your hardware, reinstalling won't help <lfam>Let's focus on Guile / Guix first <nckx>minikN: You can probably run ‘guix gc --delete [FILE NAME…]’. I also recommend a good ‘sudo guix gc --verify=contents,repair’ to check your entire store, and attempt to repair things, which will take a while. <lfam>Because that's what we can do from here <nckx>It won't solve the problem, only (a) delete that bad file (b) tell you how bad the problem got. <nckx>…that's a lot of empty files ☹ <nckx>What does /gnu/store/vngh3ksz4mbm921b9lqdk4i9g25jwvb8-xdg-desktop-database-builder contain? <dstolfa>my gut tells me the same thing lfam said earlier, though i'm leaning towards bad disk <dstolfa>with all these broken files, certainly worth a check. if both disk and RAM are good, that makes me slightly more worried <lfam>I wonder, what tool do you use to test the disk? <nckx>Eh, sorry, fail: /gnu/store/nj2iwwqcira9m2c557qwcsh070rskc3i-activate-service.scm <lfam>I know about memtest for testing RAM <dstolfa>lfam: well, my disks are checked by ZFS continuously, but otherwise i'd just use smartmontools or something like that <guiu>i was wondering why there doesn't seem to be any package for freeplane in guix <nckx>Oh. Just a different empty hash to mix things up a little. Cool. <lfam>guiu: Probably nobody tried packaging it yet! Want to give it a try? <nckx>guiu: Because nobody has submitted it yet is my guess ☺ Your chance to do so. <lfam>Sometimes it's a little tough package Java software, but we do have Java packages <nckx>Also, I'd never heard of it, which means nothing but maybe it's not well-known. <minikN>Bad RAM/Disc.. Don't know. Never had any issues with other OS, Switched to Guix 2 months ago and this keeps happening. <dstolfa>minikN: well, it's not a given that it's your hardware, but i think it's worth checking if only to rule it out and confirm a bug somewhere in guile or guix...? <lfam>Compared to other OSs (except for Nix), you'll notice corruption in the IO path more frequently on Guix <vagrantc>sometimes different workflows can trigger different hardware issues... <guiu>ok, i see. i tried to get the release code from the repository, but i realised i don't know how to get the java JRE working... <nckx>Since you're running btrfs, minikN, you could also ‘scrub’ it to make it re-check all checksums. <nckx>See btrfs --help, I guess ☺ <nckx>If that comes up clean, and you find no checksum errors from btrfs in your system logs, we might start considering Guix/Guile bugs, as surprised as I'd be. <nckx>minikN: The short one is useless [for testing this]; run the long one. <nckx>Yes, it's long ☺ Brew a thermos or 2 and get comfy. <lfam>Does SMART have a lot to say about SSDs? Also I would be suprised if a Samsung SSD fails in this way. Is that something that happens? <dstolfa>SSDs can fail but this would be a first for me.... <lfam>My impression was that the controller makes the SSD read-only before you start seeing corruption <nckx>SSDs track and report failures and statistics, let's put it that way. How reliable they are is probably beyond topic. <nckx>Meh, they can fail in infinite ways. <dstolfa>i've had SSD corruptions before due to firmware issues but never something that would result in this kind of behavior before panicking the kernel <lfam>Guess I haven't had the pleasure yet <minikN>Can I keep using my system while the test is running? :o <nckx>It will slow down both system operation and the test, but not by much, especially not at ‘normal’ usage levels. <nckx>I agree with dstolfa that SSD death would be unlikely to return neat ‘empty files’ to the kernel without killing it outright. That's a pretty high-level thing to do. Random bits or even zero reads won't do that cleanly. <nckx>But undefined behaviour is what makes computers fun ☺ <minikN>I guess I'll wait for the test to finish before running the btrfs scrub. I'll report back tomorrow. <dstolfa>if this is really a guix/guile bug, it's a pretty scary one to debug, especially since it doesn't seem like anyone else has hit it... <minikN>"Test will complete after Sun Sep 5 05:48:04 2021 CEST" :D <minikN>See you guys tomorrow. Thanks for the help so far, but I need some sleep right now (gonna cry myself to sleep over this happening continously) <nckx>dstolfa: I'm not sure. It gets reported once in a while, and the answer is usually ‘file system corruption’, and that's sometimes confirmed, but we can't know for sure. <dstolfa>nckx: would be good to find a way to reproduce it in a reliable way. i feel like minikN's config + setup could maybe be replicated in a VM to try and do it? <nckx>I hope so, because they've got the same SSD as me, and I don't want it to be that 😛 <nckx>I'm afraid the reproducer is ‘take *any* system.scm + use it randomly daily for 6 months’, but I'd be glad to be proven wrong. <lfam>Samsung is the best in the game so your odds are good *nckx appreciates the reassurance. <dstolfa>we have a bunch of samsung SSDs in production so if it really is all of samsung's lineup, i'm pretty screwed. <lfam>I think we'd have heard unless it's a bug that started manifesting 5 minutes ago *dstolfa has previously had kernel panics in the filesystem layer on freebsd on samsung SSDs, but feels that might have been his 30k line diff that had a memory corruption up until a week ago <nckx>I see you run your FreeBSD like I run my Linux. 👍 <dstolfa>nckx: what could possibly go wrong, right? <nckx>I managed to low-level destroy 3 1-TiB hard drives from different vendors by (I guess?) weird patches to my kernel. Although I'm not sure how that can happen. Still, 16 MiB between the swap and data partitions now return uncorrectable errors from any hardware. <nckx>That was a fun week-end. <dstolfa>wow, you managed to screw your data even more than i did. the worst i did was cause an infinite recursion, blew out the stack, saw a kernel panic and realized it's in the file system. with some poking in the memory, i realized that my stack corrupted filesystem memory as it was committing stuff to disk. my data was gone, but a reinstall fixed it <nckx>I've done something similar with hibernated RAM. <nckx>Turns out, you can load whatever you want as page cache. <dstolfa>possibly the most bizzare thing i've seen was when 1 CPU core thought it was another one <dstolfa>so you'd get really weird panics about a core being confused as to where its execution is <podiki[m]>easy question: how do you like to work on a package def? right now I just keep doing a `guix build -f filename.scm` but that feels inefficient <nckx>error: failed to open store @ /home/nckx/.cache/mu/xapian: Expected block 28390 to be level 2, not 0 <nckx>Dammit, I invited the corruption in, didn't I. <nckx>podiki[m]: I work from a git checkout, and I do just use ‘./pre-inst-env guix build <package>’ (no -f needed since I'm editing the module in place). <podiki[m]>this is for a new package definition so I hadn't yet put it in the guix packages, but I guess would need to for a patch <nckx>I don't know anyone who uses fancy REPL magic to work on packages like that. So you might be disappointed by the answers *or* I'm about to learn something cool along with you. <podiki[m]>mostly I'm guessing at some inputs because I don't understand qt naming sometimes, but felt like there might be some cool scheme way to discover while building <podiki[m]>otherwise I guess working in the failed build directory to use the environment variables and debug specifics? <nckx>So I've heard some people mention working from the --keep-failed output like that, in a (guix) environment with the environment (variables) loaded manually, and I guess it works for them. Not something I've tried, though. <nckx>OTOH I never fell in love with the REPL like some people have, maybe that's a similar feeling. Jump into the muck! Get dirty. Whee. I like spinning up clean rooms each time… <podiki[m]>I love the repl from common lisp, but for packages you are not just living in lisp land unfortunately <podiki[m]>we're using gcc 7.5 by default in build systems? <podiki[m]>I don't see an argument for it, so I can just put gcc-toolchain as a native-input and it will use that for build? <podiki[m]>(working on a package that needs gcc8; it is for hardware fan control and the like) <vagrantc>the make-arm-trusted-firmware function shows how to use a newer gcc ... <podiki[m]>i just put it as a native-input and seems to work (I remember doing that for another tool, can't remember which) <podiki[m]>but thanks, will make sure I'm doing it correctly <nckx>(It's a good example but it's a bit verbose if you don't know what's relevant. Only the native-inputs field.) <lfam>On core-updates we're using GCC 10 <vagrantc>yeah, it has a lot of crossbuilding support <podiki[m]>luckily this didn't need anything fancy, just had the filesystem headers that went mainstream in 8 it seems <vagrantc>i vaguely recall it being bumped a bit higher <podiki[m]>for those interested, also have packages of python-autokey, openrgb (needs some debundling I think), and some more random stuff I need to submit patches for <podiki[m]>the build system stuff in guix is quite nice though, works well even for a newbie <nckx>‘so usually you end up with multiple control programs installed and running at the same time’ <nckx>That looks very cool compared to our current (very TUI-centric) selection! Thank you for packaging it. <podiki[m]>openrgb is quite cool too, funny that the only rgb light option on linux (that I know of) is one that does everything rather than all the manufacturer proprietary stuff <podiki[m]>nckx: just gotta get it to fully run now, but the build was about as straightforward as it gets (so far) <muradm>warning: the 'target' field is deprecated, please use 'targets' instead <nckx>muradm: Should be as simple as (target "/dev/foo") → (targets (list "/dev/foo")) <nckx>/boot/foo if you use UEFI. <muradm>nckx: yeah, just done so already after looking up bootloader.scm <muradm>but that error.. i didn't change anything.. <nckx>If your bootloader isn't broken. <nckx>Is /boot/{,efi} mounted (correctly)? <muradm>i suppose there is a problem with laptop's nvram <nckx>I've never seen that error. <nckx>GRUB (well, efibootmgr) is usually very explicit about that happening. <muradm>by the way is there is a way to run guix reconfigure without applying bootloader everytime? <muradm>that writing nvram thing sometimes killing me <nckx>You can use (installer #~(const #t)) in your system.scm to do the same persistently, since you normally need to install GRUB only once. <nckx>Stilly, you lose the right to complain to support if a GRUB update does break that. *nckx was very proud of themselves for not replying ‘guix system reconfigure | grep bootloader’ -- now that's progress. <nckx>Er, s/reconfigure/reconfigure --help/. <nckx>Search results for your error messages are, in order: people who don't know how mount works; people using devicemapper; people using nontrivial btrfs subvolumes. Are you one of the latter 2? <nckx>Does /boot/grub itself exist? And (obligatory) you are root, right? <nckx>With sudo that is, I don't mean you need to ‘su’ or log in as root. That could create more problems. <podiki[m]>I also recently setup btrfs with subvolumes, but didn't need to do anything special with all subvolumes being top level; there are some notes in the manual about nested subvolumes though <nckx>Just to make sure: you mean /boot/efi, right? <nckx>I also don't think btrfs subvolumes are to blame if that same configuration worked fine until recently. <nckx>I'm a bit lost for ideas myself, sorry. <podiki[m]>question about package inheritance: if I just want to change a configure flag but the parent package does a whole replace 'configure <podiki[m]>do I need to copy the whole thing and modify that or will changes I make in sibling package overwrite just part? <muradm>nckx: could be like "if (prev-generation-bootloader-drv != new-generation-bootloader-drv) { run new-generation-bootloader-drv } <nckx>podiki[m]: Look for examples of ‘substitute-keyword-arguments’ in the guix tree. <muradm>but i'm not sure if prev-generation-bootloader-drv is accessible when building new one *nckx confused podiki[m] & muradm above. <podiki[m]>ah, but parent package does substitute on the Makefile, ...hrm <nckx>You can still use modify-phases on the result to delete phases from the parent package's phases instead of %standard-phases. <muradm>podiki[m]: if configurure flags are within some phase and not in #:configure-flags, then you will need to rewrite phase <muradm>substitute-keyword-arguments is your friend for minimal intervention <nckx>podiki[m]: It's possible (I can only guess without examples) that the parent package does ‘too much’ in a single phase. It's not uncommon. It's fine to submit a separate patch to split that monolithic phase into 2 ('patch-stuff, 'configure) first. <nckx>If the parent package's 'configure phase doesn't accept a configure-flags keyword that's also a bug. <podiki[m]>this is for pciutils, the corectrl package I'm working on doesn't seem to like the compressed hwids from pciutils <podiki[m]>pciutils replaces configure phase with makefile changes <muradm>nckx: regarding bootloader, i was meaning that, just like package is being NOT rebuild if hashes match, same could be done with bootloader, if configuration didn't change, i suppose that script created to update bootloader will match by hash with previous generation script. in this way bootloader will not be updated everytime. then instead of providing --no-bootloader, it could --force-bootloader.. :) <nckx>OK, so there is no notion of ‘configure flags’ to respect. <podiki[m]>so I could add a phase after configure that also patches the makefile, so that it would be done in addition (but after) the parent changes? <nckx>muradm: That sounds awfully familiar (and obvious), I'm almost certain there's a bug report suggesting that. <podiki[m]>muradm: I also like that idea, writing grub always makes me nervous anyway, and honestly so rarely need to actually make changes there <nckx>podiki[m]: De gustibus, but it doesn't sound hacky to me. Phase names are just names, it's not discouraged to have 'configure and 'configure-some-more ☺ <muradm>nckx: great then :) i'm not alone :) you know on the long run for efi users nvram has limit on number of writes :D <nckx>muradm: True, although I'd argue that efibootmgr should do a {read, check if modified, write only if so} check itself, too. Maybe it does. Dunno. <podiki[m]>nckx: sounds good to me, then it gets a nice descriptive phase name too <muradm>nckx: i suppose in my case, right now efibootmgr can't even read from nvram :D <nckx>muradm: I'm a bit busy, could you try searching the bug tracker? <nckx>I'm still not convinced that this has anything to do with NVRAM? Unless you know more. <nckx>NVRAM errors *are* common but they tend to have different symptoms. <nckx>Do you mean efibootmgr fails to read when invoked manually? ***apteryx_ is now known as apteryx
<nckx>I thought there were objections raised but apparently not. Or not there. <nckx>Feel free to (constructively, not just "+1") restart the discussion. <nckx>I don't use GRUB so no real opinion... <muradm>nckx: nvram chips used for efi are cheap and fragile, designed to write few times in life time. previously i used carbon x1, after switching to guix, few times i had to reset its nvram :) now i have lemur pro, it does not require manual intervention, it rests it self :D then i have to boot from usb to run grub-install :D <muradm>also if it happens that you have other OSs collocated, like W-os, some of their configurations especially when disk is encrypted fail to boot if just time stamp of a file on /boot/efi is changing <nckx>I thought it was closer to 100,000 writes but no reason to be wasteful in either case. <muradm>if i remember correctly it should be around 10,000 <muradm>for W-os, i had to enter bitlocker security serial like everytime i boot it after guix reconfigure <muradm>at least i don't have W-os problem on lemur now :D <nckx>Obvious bug in Windows (and I'm pretty adamant that Guix need not put effort into working around obsolete + proprietary operating systems) but not itself an argument against #44898. I think the main argument would be how to reliably detect ‘the same GRUB’. Saving the hash to a file is too weak (the bootloader might be damaged/removed), and grubx64.efi is created on the fly by grub-install, we can't simply compare the installed version against one in the store. <nckx>Clever ideas welcome :) Or the eternal cop-out: support skipping the installation of GRUB based on a previously cached hash, but don't make it the default, and warn about the risks in the manual. <nckx>It's what people are doing with the (const #t) trick already anyhow. <muradm>nckx: that is not bug, it is security feature :) when you have win10 connected to business AD, it enforces policies, encrypts hdd and on boot does some checks, if it finds that something fishy happened between the boots, it forces you to enter security key which you can acquire from sysadmin <dstolfa>sounds like SELinux for most people. a security feature that everyone disables if they can :P <muradm>so that is not supporing windows, but supporting users which move to guix, but have to use win :D <nckx>I'm not disputing that Windows does that, or that it does that by accident (/me eyes tinfoil hat), but I think it's hard to claim that it has anything to do with security. How is it not a bug? <nckx>This is like SELinux suddenly locking the system because you changed a file on your NTFS partition. <dstolfa>yes well we're talking about a company that refuses to support IMAP on their email... <nckx>Right. I get that the word ‘security’ here is not used in its human sense, but as a magic word to make the annoying questions go away. <dstolfa>this is the same notion of "security" that laptop vendors use to allow only certain wifi devices in the laptop... <dstolfa>or the notion of "secureboot except only microsoft keys are allowed" <nckx>Not that I disagre, buut... FCC certification is actually a more plausible excuse? <dstolfa>i wonder how many of those laptops had anything to do with FCC certification <dstolfa>and how many were mostly paid by vendors *nckx shrugs -- more plausible than ‘claiming you now own the entire EFI system partition and that it's not a bug or a deliberate anti-competitive move’ is not a high bar. <nckx>They're both on the bottom of the cess pool. <nckx>It's just quite clear there's no way to claim it's a security feature. <nckx>(Not directed at muradm but at Microsoft, of course!) <muradm>nckx: for this matter, i may agree with M$ :) especially EFI is so powerful, that it is not hard to compromize laptop by replacing *.efi files :) <muradm>I don't need that personally, but some paranoiacs not technical people, is useful feature for them <nckx>Well, I don't, but that's fine :) It's not really relevant to the GRUB thread either way. <muradm>nckx: I hope you will like my solution with spliting phases :D <nckx>‘Paranoid non-technical people’ is probably exactly what this is aimed at. No disagreement there. <iskarian>Does anyone have a way of filtering failed CI builds by their log contents (specifically, filtering out "missing derivation" failures?) <muradm>regarding detecting if grubx64.efi is changed, i don't think that it is necessary to be so precise <muradm>even if grub version is changed, *.efi files are quite standalone binaries <nckx>Does it not load separate module files from /boot/grub? <nckx>If so there could be ABI issues. <muradm>currently i have /boot/grub also encrypted <muradm>what it does is prompts password, mounts /boot/grub and loads /boot/grub/x86_64-efi/grub.efi <nckx>muradm: Oh that's interesting. Why all the modules in /boot/grub/x86_64-efi then? Are you saying they aren't used and all baked into grubx64.efi? <muradm>should not be any interface there or abi issue <muradm>if they would be used, i would see graphical grub :) which i don't :) <muradm>i mean i see it after grub.efi is loaded <muradm>but not before, there is no access to them any way <muradm>in before on arch i was using systemd-boot, also minimal efi only bootloader, it was installed only once with arch install like in 2014-2015 and never updated again :D <nckx>I've ssh'd into an UEFI server I forgot I had. /boot/grub/x86_64-efi/grub.efi doesn't exist (and it would have to be on /boot/efi to work). /boot/efi/EFI/BOOT/bootx64.efi (a renamed GRUB because vendor firmware is cancer) is 288K. I want to believe you, but I do find it strange. <nckx>The way I remember GRUB working on BIOS systems is that only the minimal set of modules needed to find /boot/grub/ is embedded, the rest loaded at run time. <muradm>is your server fully disk encrypted? :) <nckx>I'd expect the same here: grubx64.efi containing an ext/btrfs/whatever driver (but only 1!) and maybe cryptodisk, nothing more. <muradm>if not, yes you will get bootx64.efi <nckx>No, it's not, but GRUB can read from encrypted disks just fine. <nckx>It wouldn't have to embed all the modules, it could still load them later. <nckx>Just because /boot is encrypted I mean. <muradm>exactly, grubx64.efi contains what you listed with minimal cryptodisk as far as i remember <muradm>this layour is necessary if grubx64.efi is only which is outside of LUKS <nckx>That seems to contradict the statement above that it loads no external modules at runtime. <nckx>Just off the top of my head, I'm thinking jpeg, unifont (which is required to even display text on the vast majority of UEFI systems). <muradm>if (disk-encrupted) { install bundled grubx64.efi } else { install off the shelf bootx64.efi } <nckx>I renamed it to bootx64, not grub. <nckx>GRUB installed grubx64 but my firmware is stupid :) <muradm>they are not used on that phase, when laptop boots and loads grubx64.efi, you see like "Welcome to grub, enter password for hd0.gpt1: " and nothing more :) <nckx>I really wish I had a LUKS UEFI system right now. <nckx>Out of curiosity, how big is your GRUB .efi file then? <muradm>then it unlocks hd0.gpt1, and loads grub.efi <muradm>/boot/efi/EFI/Guix/grubx64.efi 364544 <muradm>/boot/grub/x86_64-efi/grub.efi 364544 :D <nckx>That's why I don't get your ‘grubx64.efi unlocks the disc, then loads grub.efi’… <nckx>If GRUB particularly enjoys loading identical copies of itself into RAM, it can already do so until its socks fall off, without having to unlocking /boot/grub… <nckx>I'm also superverytired so I think I'll head off to bed. <muradm>nckx: $ diff /boot/efi/EFI/Guix/grubx64.efi /boot/grub/x86_64-efi/grub.efi <muradm>Binary files /boot/efi/EFI/Guix/grubx64.efi and /boot/grub/x86_64-efi/grub.efi differ <muradm>they will, coz as far as i know grub-install hardcodes partition uuid which should be unlocked if disk encrypted <muradm>because at this stage there is no access to any configuration <muradm>any cloud service provider provides guix machines yet? <EdLin>any suggestions for free-software compatible discrete GPUs? guix won't work with my AMD GPU in a threadripper system, and it only works with a discrete GPU <dhruvin`>I created image and uploaded it to DigitalOcean. Worked fine. Couldn't "guix system reconfigure" the system afterwards though. <podiki[m]>EdLin: new amd gpus will "work" but only at a lower resolution and I think without hardware acceleration; maybe older ones are less constrained? <EdLin>podiki[m], it's a rx 5700 xt <EdLin>no radeon driver, only amdgpu <podiki[m]>I had to use nomodeset kernel parameter to boot the guix installer, and it only ran at 1024x768, but it did work (this was a newer card) <podiki[m]>the problem isn't amdgpu it is the lack of the binary firmware blob, which you can't do with linux-libre *muradm scratching head if should ditch ansible in favor of "guix deploy ..." <dhruvin`>muradm: I'n not sure why. Couldn't find time to find it. <muradm>i just wander if any cloud hosting provides guix out of the box.. <muradm>linode starts charging for images <voroskoi[m]>Vultr has byo iso, that should work, but i have never tried <muradm>ah, many supports that, no issue with support <muradm>problem is with out-of-the-boxeness :) <muradm>i created image on linode months ago, without an issue, <muradm>now i needed another server, but that image is old now, guix pull/guix reconfigure takes a while <EdLin>what's the proper syntax for guix system reconfigure? <EdLin>ah, I was missing that file. <dhruvin`>I'm new to guile programming. I'm working on guix image for sourcehut builder. Does anyone know how could I get a channel from its string representation? i.e "(channel (name 'somechannel) (url \"example.com\"))" -> (channel ) <muradm>raghavgururajan: that capsul config included /root/capsul-init <raghavgururajan>muradm: It is their internal script to setup VPS with users, ssh-keys, passwords etc. <muradm>(string->symbol "example.com") -> 'example.com <raghavgururajan>muradm: Did you choose f1-xs? Guix System won't work with that. Start with f1-s. <dhruvin`>Ignore to substitutes part in that paste. <muradm>dhruvin`: try (use-modules (ice-9 eval-string)) (define channel-read-from-string (eval-string "(channel ....)")) <muradm>dhruvin`: cool.. that sr.ht thing <muradm>dhruvin`: but i would suggest to do some checking of string before calling (eval-string <muradm>cpu/network performance is incomparable of course with linode <bricewge>dhruvin`: There is `sexp->channel` buy you need to get a sexp from your string <EdLin>I can't seem to get geary to build in guix. <EdLin>(geary is a GNOME email client) <muradm>guix deploy: sending 37 store items (298 MiB) to ... (face palm).. :) <EdLin>gnome boxes keeps claiming my system has no virtual machine extensions. <EdLin>yet /proc/cpuinfo on my guix system includes svm <EdLin>hm, how do I set boot parameters for GRUB in guix? <EdLin>I don't see /etc/default/grub so it's somewhere else... <muradm>EdLin: which parameter you want to set? <iyzsong>EdLin: it's "kernel-arguments" (list of string) of "operating-system" (the system config record) <EdLin>muradm, never mind for now, it was complaining about kvm modules because the vm script wasn't being run as root <bricewge>Even building guix on linux-libre 5.12.19 (I was on 5.14), it still on `statfs` test. <bricewge>When I run the test in my current guix repl the test pass <muradm>bricewge: make check-system TESTS="statfs"? <minikN>Is there anything I can do to delet corrupted store files if `guix gc --delete ...` reports `is still alive` ? <bricewge>No, `./pre-inst-env make check TESTS="tests/syscalls.scm"` PASS <bricewge>muradm: But `./pre-inst-env guix build guix --no-offload --check --no-grafts` fail <bricewge>I've checked ci.g.g.o and data.g.g.o but there is no failure there which is odd <bricewge>I really don't understand what happened here, it's probably the 7th time in a row I tried building it <bricewge>“derivation `/gnu/store/6gig7qi7jcw790iy5q5ynvbf9mrhs6xc-guix-1.3.0-5.6243ad3.drv' may not be deterministic”... *muradm SKIP: tests/syscalls.scm <EdLin>I can't seem to get guix system vm to make anything other than a blank screen. <EdLin>I see it boot, but when it reaches the X greeter, it is blank <EdLin>is this the help channel or only for development? <muradm>EdLin: may be you paste configuration which you are trying to run.. ) <muradm>bricewge: but in the end guix build: error: derivation `/gnu/store/6gig7qi7jcw790iy5q5ynvbf9mrhs6xc-guix-1.3.0-5.6243ad3.drv' may not be deterministic: output `/gnu/store/09alp50cr54p6iyh1vi0dkmrnqplzdrf-guix-1.3.0-5.6243ad3' differs <EdLin>muradm, is there a pastebinit type program in the guix repos? <muradm>EdLin: no idea, i do that in emacs personally, never used separate program, but "guix package --search=pastebin" seems to report some <EdLin>I'm a bit of an emacs noob, and a lisp noob. Maybe I've gone into the deep end here. <EdLin>oops, now everone knows my real name. <shudder> <muradm>is that vm config you are trying to run? <EdLin>yes, it's barely modfied from my installation <EdLin>maybe I need to make a new one from scratch? <EdLin>I wouldn't know where to start. <bricewge>EdLin: `set-xorg-configuration` is missing a second argument <muradm>bootloader set to /dev/nvme2n1 .. <EdLin>it fails when it reaches the X11 greeter <muradm>there is also missing "input" group for user i think <EdLin>ok, added input, and also installing to /dev/sda in the VM <bricewge>EdLin: My bad the second arg is optional <EdLin>same result though, blinking cursor <EdLin>after booting to console and starting up gdm I assume <raghavgururajan>> murdam: cpu/network performance is incomparable of course with linode <EdLin>incidentally, gnome boxes is broken, it thinks I don't have svm active in BIOS <EdLin>that I'm pretty sure is not the case <EdLin>let me double-check though, I know I've used VMs on this system before however. <EdLin>/proc/cpuinfo says it is also <EdLin>so I don't know why gnome boxes is broken in GNOME's default install <EdLin>maybe this is related to the vm problems I've had with the guix command, but I doubt that... since it does boot. ***Exagone313 is now known as Exa
<lilyp>EdLin: for the record, are you in the kvm group? <lilyp>If not, then you can't do any of the kvm stuff with qemu, which is on the one hand important for performance and on the other might be wanted by gnome-boxes <pkill9>does guix have an easy to use commandline mail client? <muradm>pkill9: what do you mean easy to use? on linux there is basically not much choices on mail clients <lilyp>"easy to use" and "commandline mail client" sound mutually exclusive, but it does contain git send-email :P <muradm>everyday use would be something like: mbsync + notmuch/mu4e + some frontend for your taste <sneek>Welcome back maximed, you have 1 message! <sneek>maximed, iskarian says: maybe try guix lint -c derivation to run a bunch at once? <muradm>frontend options: mutt, neomutt, emacs <muradm>or if you really need command line, you can stop at indexers, which are notmuch/mu4e :) will provide you nice cli tools to search view emails :) <muradm>any one using "guix deploy ..." around here? <muradm>maximed: yeah, mutt one of them :) <pkill9>muradm: something that requires little to no configuration and obvious keybindings <pkill9>e.g. you just give it email account details and then you can use it <muradm>pkill9: that would be hard, you will need to invest anyway <maximed>mutt didn't need any configuration but the SMTP and IMAP (or two other protocols) information, and something for TLS I forgot about <muradm>i would suggest to first setup mbsync, that you will need any way <muradm>then look at mu4e, i find it easier than notmuch <muradm>maximed: one will have too much pain connecting mutt straight to imap/smtp :) <muradm>bricewge: do i need to run "guix pull ... " on remote hosts? <muradm>currently when i do "guix deploy ..." it just says warning about provinence suggesting guix pull some times <muradm>i will try to send email guix-devel with impressions and questions i gets on guix deploy... :) <muradm>searched issues.guix.gnu.org for "guix deploy", most issues reported by bricewge and pkill9 :D <dstolfa>sneek: later tell lfam: my download's done, i have 300G of stuff now (compressed) and can serve it if needed for a download <sneek>Welcome back dstolfa, you have 2 messages! <EdLin>muradm, I connect Mutt straight to a friend's IMAP/SMTP server for his business. <EdLin>I did need to set up caching though, but that's mutt features. <EdLin>with message cache and header cache enabled, it performs well <dstolfa>sneek: later tell minikN: seems like the disks are fine (and i assume RAM is fine too, given that smartctl and btrfs agree). this seems to point to a guile/guix thing potentially. <muradm>EdLin: lucky you.. me had so much pain years back, never want to touch that again.. :) <brendyn>Is it just me or are the arguments to string-prefix? backwards? <brendyn>in particular, It cannot be used with lset-difference. One must run (lset-difference (lambda (a b) (string-suffix? b a)) l1 l2) <dhruvin`>Can someone help me figure out why there is no '(git) in (source-module-closure '((guix channels)))? <cbaines>dhruvin`, as the default for #:select? is guix-module-name? <cbaines>even if that was changed though, pulling in the scm file isn't appropriate for the git module, the relevant package is needed instead <dhruvin`>Context: I've been working on sourcehut builder image. I created a shepherd service that adds channels to build user's profile's channels.scm. <dhruvin`> (with-imported-modules (source-module-closure '((guix channels))) <dhruvin`> (let ((extra-channel (eval-string channel-definition))) <dhruvin`>I guess I shouldn't have pasted that here. <dhruvin`>Ignore the substitutes bit mentioned in the paste. Hope I'm not spamming everyone here. <dhruvin`>I intend to take the channel definitions from the repositories key in said build.yml file and populate channels.scm with them. <voroskoi[m]>is there a public guix substitute server list somewhere, or ci.guix.gnu.org will use the nearby mirror? <roptat>I thought the manual had a list, but apparently not <podiki[m]>if a package has polkit files (in share/polkit-1/) does that require extending the polkit service? <podiki[m]>or just including polkit in inputs? (seems this is the case in examples, but for a package I'm working on doesn't seem like these files are seen by, in this case, kauth) <roptat>not sure how it works, but I think this might be because of a missing environment variable? <roptat>mh, no, you probably want to extend the polkit service <podiki[m]>ok, maybe I'll try that. like for udev rules, but not like dbus rules.... <roptat>you can add something like (simple-service 'my-polkit-service polkit-service-type (list foo bar)) where foo and bar are packages that provide polkit files <roptat>although, polkit-service-type is not exported for some reason <roptat>ah nevermind, it's in (gnu services dbus), and it's exported, I wasn't looking at the right place <lilyp>raghavgururajan: GTKmm should still use the old synopsis imo, otherwise lgtm <roptat>I'm a bit hesitant about applying it, because then "ocaml" is no longer compatible with the other ocaml packages (you have to specify ocaml@4.11 instead) <roptat>it'd be great if we could switch to ocaml 4.12 by default <roptat>at first glance, looks good though <podiki[m]>and looks like polkit-service-type is not in the manual (unlike udev-service-type for a similar thing) <yoctocell>roptat: What do you mean by "because then "ocaml" is no <yoctocell> longer compatible with the other ocaml packages (you have to specify <yoctocell>I am not changing the default `ocaml' package <yoctocell>also, ocaml 4.13 is going to be released soon, so it might be worth waiting for that and making ocaml 4.13 the default compiler <roptat>yoctocell, sure, I mean in a command-line <roptat>you can't install both ocaml and ocaml-findlib at the same time, findlib won't work, you'll need ocaml@4.11 and ocaml-findlib <roptat>almost got adb building, but failed in the link phase :/ <roptat>(I managed to dodge the dependency on the whole SDK) <podiki[m]>roptat: thanks, that got me further, but back to something I've hit before, of dbus not seeing a package's dbus files <roptat>maybe you want to extend dbus too? <podiki[m]>I don't think I should need to, right? other packages with dbus files get picked up <podiki[m]>in this case looks like it is system-service dbus files in the package, maybe that's why they are not seen. I'll try extending dbus <yoctocell>roptat: ah, ok, the ocaml on the cli refers to the latest version <yoctocell>that would make things a little bit annoying <yoctocell>I will probably wait for 4.13 to be released, and then make it the default compiler <sneek>Welcome back nckx, you have 2 messages! <nckx>minikN: ‘# 1 Extended offline Completed without error 00% 8219’ is what changed, so that's good. <nckx>muradm: That's because grub/grub.efi reserves a few zeroed bytes for the device name that are ‘filled in’ when installing (install diffoscope & xxd for a better view than ‘diff’), but this has nothing more to do with loading modules, and they must still be loaded from the cryptodisk. With the cold light of day on my noggin I'm also not sure why we were discussing this at all, I think we got side-tracked. :) <muradm>nckx: :D right, it does not matter :) what do you think about comments on that resurrected issue? :) <cwebber>trying to compile the custom u-boot for the mnt reform <cwebber>let's see if I can figure this out... <nckx>muradm: I'll reply via mail when I get to yours later! <charles_>Is there an easy way to update a lot of packages? ***charles_ is now known as char
<nckx>char: Depends on the specifics. ‘guix package -u’ takes one or more regexes. It can also take a manifest file, but that implies updating all packages in the profile, not part. <char>nckx: What I really meant is updating the package definitions to latest upstream release or git commit. <nckx>Take a look at ‘guix refresh -u’, for relative values of easy. It claims to be able to update 90.8% of packages automatically, but you will need to have a git development Guix set up. <nckx>(guix refresh -L lists stats for each updater.) <nckx>See ‘Invoking guix refresh’, which links to ‘Running Guix before it is installed’, in the Guix manual. <nckx>It's not magic but it's currently the best option. A human eye and some testing of the result is always required. <minikN>nckx: I reinstalled Guix this morning. I couldn't delete any corrupted files necause they where still alive. Didn't know what else to do so I started anew. However, I did install it on another sdd just to rule that out. <sneek>Welcome back minikN, you have 1 message! <sneek>minikN, dstolfa says: seems like the disks are fine (and i assume RAM is fine too, given that smartctl and btrfs agree). this seems to point to a guile/guix thing potentially. <minikN>dstolfa: You could be right about it pointing to guille, if there is anything I can do to hrlp debug this let me know. I guess since I reinstalled that's out of the picture for now. But if it doesn't hsppen again it had to be related to that ssd somehow, if it does happen again I'll be messaging you guys. <podiki[m]>nckx: woop, got corectrl built and functional (with some digressions into polkit and dbus); still will need some testing and cleanup before submitting, but wasn't too bad <excalamus>I need g++-multilib. Specifically, I'm trying to solve a ImportError: libstdc++.so.6: cannot open shared object file: No such file or directory <nckx>I thought ‘multilib’ was that weird /lib{32,64} thing that some distros used to to. libstdc++.so.6 is provided by the ‘gcc:lib’ output, but it should be present by default in the build environment. What are you building, excalamus? <excalamus>that's my understanding, too. I'm trying to build Plover from source, running their tox script (tox -e launch) and fixing errors that come up. <excalamus>ultimately hoping to fix some issues with the current Plover package <nckx>I've never had much fun with Tox, and since it's just a usel^Wthin wrapper around commands that usually work I tend to ignore it. You're running this build inside Guix, though, right? <excalamus>I've never used tox, so just following their dev notes. Yes, I'm using guixsd. Did git clone of the Plover repo and have been running the tox launcher and fixing errors that come up <nckx>I never build nontrivial packages outside of a Guix package definition, but it should work if your environment's set up correctly. <nckx>The problem here might be that gcc:lib is a hidden package and gcc-toolchain doesn't have a :lib output? I dunno. <iskarian>excalamus, are you trying to build within e.g. `guix environment plover`? <iskarian>(personally I rarely work directly on packages, like nckx I usually just modify the package definition and re-run `guix build`) <nckx>Yeah, we'd need to know more about how exactly you're providing the packages that Tox/plover need. <excalamus>I can update the stenography.scm and get a build of the latest, but it has problems I'm not able to reason through without knowing more about how Plover works. <iskarian>Another way you can work is building with -K, then when it fails, go to the /tmp/guix-build... directory and source "environment-variables" <nckx>Try again in a ‘guix environment plover’ as iskarian suggests. It avoids the subtle differences like gcc/gcc-toolchain that muddy waters. <excalamus>just cloned the git and started running their tox -e launch command <iskarian>(you'll also want to clean the environment, so before sourcing, a `guix environment plover` or `env -i` at least) <iskarian>that's `guix environment plover --pure`, sorry <excalamus>okay, what does the plover in guix environment plover do? Install the known plover dependencies? <iskarian>Well, not install; it creates a profile where they are available, and then enters the profile. --pure makes sure you don't see any environment variables or such from your current environment <excalamus>In `guix environment --pure`, tying to run tox fails because it's not there. Since it's pure, there's no guix. I'm missing something, clearly <nckx>In Guix, ‘install’ just means ‘make available in this context (environment)’, and your daily user environment is just a special more persistent case of that. <iskarian>That's correct, because the plover definition does not have tox as an input. <nckx>guix environment plover --ad-hoc tox [other packages…] <nckx>Leave the current environment, then arrow up, edit & enter that one. You could add guix to your environment and keep nesting them like dolls but don't. <iskarian>(I believe the package is called "python-tox") <excalamus>So, the idea is to keep ad-hoccing until I (maybe) run into the same ImportError in order to rule out that it was the environment which caused the issue? <excalamus>creating a guix environment plover --ad-hoc python-tox and then running the tox -e launch results in the ImportError: libstdc++.so.6: cannot open shared object file: No such file or directory I've been getting <iskarian>excalamus, which plover definition are you using? master or core-updates-frozen? <excalamus>What do you mean? stenography.scm? Whatever comes up with guix-edit <excalamus>But I'm doing this stuff from master of the plover git <iskarian>I'll take a quick look at it and see if I can't find something right off <excalamus>If you're willing to continue helping me, we're in a bit of an XY with the whole "build from the git repo directly path". Ultimately, there are two things I'm trying to do: 1) build plover so that it supports plugins. I was told by the Plover people that was possible in the dev10 version, yet when I update stenography.scm to create dev10 (which it does), plugins still appear to not work. <excalamus>and then 2) get icons to show up. Right now I have to use tooltips to identify anything in the application :) <excalamus>(and, tangentially, learn how to actually package things in Guix) <iskarian>Okay, so to walk through what I'm doing... first, I'm running `guix build plover -K --with-commit=plover=v4.0.0.dev10` (-K tells guix to keep the build directory, and with-commit should be pretty clear) <iskarian>So, since it built fine, what is the problem? Is there a config options we need to enable plugins? <excalamus>The Plover folks say that I shoud see a plugins button in the top button menu, beneath the menu bar. <excalamus>When I ask them, they inquire about pip etc. But of course that's not how we (directly) install stuff in Guix-land <excalamus>They say I need to install plover-plugins-manager through pip <iskarian>Ah, are plugins meant to be installed as separate packages, then find-able from inside Plover? <excalamus>I'm not quite sure. They have this plugin manager which then loads them in. I think as Python packages? <excalamus>Not like "python package" is really specific <iskarian>Well, first this is probably to make the plover-plugins-manager package. <excalamus>That's what I was thinking. guix import plover-plugins-manager? <iskarian>Let's do a `guix import pypi plover-plugins-manager` <excalamus>(not trying to jump the gun, trying to demonstrate effort!) <EdLin>pip doesn't work in NixOS, because of the non-standard FSH, it probably doesn't work in guix either? <iskarian>You're good :) I'm glad you're aware of import <iskarian>actually, we'd probably want a `guix import pypi --recursive plover-plugins-manager`, it looks like we'd actually need to add several packages <excalamus>When I was approaching things previously, I needed python2-dbus and a few other things that aren't directly in the stenography.scm defn <excalamus>EdLin, you're fine in my book. Any help or perspectives I can get, I sincerely appreciate. <podiki[m]>would it be considered a guix bug if syncthing-gtk, when checking the option for autostart, makes an improper desktopfile? it execs .syncthing-gtk-real instead of syncthing-gtk (so it doesn't work) <podiki[m]>I'm not sure how to fix it (haven't looked yet), but guessing it just creates it on the fly and gets it's running path (hence the .real) <iskarian>Typically things like plugins works like: the plugin installs file to a system-wide directory like /lib/python/site-packages, and then the main program can see those when it runs <iskarian>Since packages are meant to be mostly self-contained, typically in Guix we would either include all the plugins in the main package, or define a search-path for the main package. <iskarian>So as I was saying, I'll just do that recursive import, pipe the output to a 'plover.scm', add the appropriate imports, and try to build it <excalamus>That makes sense. Whenever I've made Python pluigns, I directly worked with importlib. They appear to be doing something with setup.py (don't quote me). <iskarian>I'm trying to build it with `guix build -f plover.scm`, but it hangs, which means there's a dependency cycle <iskarian>Hmmm. I just happened to look at the plover documentation, and it says it has a built-in plugin manager? <excalamus>To make sure I'm following your process, you generated what's in the pastebin using the output from the guix import call? <excalamus>Yes, the built in plugin manager doesn't appear to be actually built in, in the sense of in the master branch <iskarian>excalamus, yes, except it did not automatically generate the use-modules block, and it automatically made an entry for python-plover, which I removed, and then changed the "python-plover" input to "plover" <excalamus>I'm only able to talk with plugin devs atm and they're only able to say that the plugin manager is available from the distributed plover builds or from the pypi package <excalamus>Since we can build and run dev10, or from HEAD, and it doesn't have the plugin manager, I conclude that it's not included in the main repo <iskarian>When I run it, I see a "Plugins" tab in "Configure" <excalamus>No, I don't think that's it. Let me confirm, but the build I'm working with has no functionality to it; it's just a blank table. I have no icons, but I don't see any tooltips indicating there is a "load plugin" button or the like <excalamus>Yes, just confirmed with them, the pluign manager is NOT accessed through Configure > Plugins, but instead throuh a button on the main window <iskarian>I see. I think that the functionality of a plugin manager that installs to e.g. /lib/ is not compatible with Guix. We would instead have different Guix packages for each plugin, and the install process would install them in the right place. But if it installs to the user's home directory, that would be different <iskarian>But if the plugin manager installs plugins to the user's home directory* <excalamus>That was my thought (literally talking with the Plover folk on the other line about it). I (once I knew how) would package up any Plover plugins as separate guix packages <iskarian>Where does Plover look for plugins? Does it honor an environment variable? <excalamus>I'm being told that plugins are expected to be in site-packages. However, the emily-plugins.py I linked is apparently not a plugin, but a dictionary... <excalamus>But there's a plugin for loading python dictionaries (dictionary here is a steno dictionary, a mapping between things like PHROFR and "Plover", not a Python dict {}) <iskarian>That's good news! Plugins should Just Work, assuming they use a setup.py or similar <iskarian>what do you mean? It's supposed to be GPL2 but it's missing a license file, is all <excalamus>I know guix has a strict policy of keeping to libre software. Plover is free, but github itself is not. <vikanezrimaya>it's hard to avoid GitHub if something is only hosted on GitHub <vikanezrimaya>one will need to rehost it somewhere else then and even then you'll need to eventually pull upstream changes <excalamus>I just meant if it was okay to link to github within the IRC. Nitpick, maybe, but wanna make sure I'm following the rules :) <maximed>excalamus: Linking to GitHub for linking to a free software project should be ok <iskarian>excalamus, I have to go for now but I'll be sure to get back with you later :) <maximed>if you was linking to GitHub itself (and not a specific repository) to promote GitHub, probably not <excalamus>iskarian thank you for your help. I'll try packaging up the plover_python_dictionary and including that as a dependency to the plover-dev10 <excalamus>I'm sure that will create learning opportunities <moshy>I checked with IceCat and it didn't flag anything up in LibreJS. Although it's possible to get the download link for a repository using Emacs, then wget <nckx>raghavgururajan: No, it's not needed there.