<florhizome[m]><jgart> "Anyone interested in porting..." <- we port guix, they port their kernel? <jacereda>why isn't make-linux-libre exported from linux.scm? <rekado>jacereda: I asked myself the same question <rekado>you can access it with (@@ (gnu packages linux) make-linux-libre) <rekado>perhaps it’s not exported because it’s not a nice API <rekado>I think these procedures are still pretty verbose and require too much plumbing <nckx>Something change about the default Guix emacs indentation rules? The second and subsequent elements of (at least) package arguments now indent badly to the right. <podiki[m]>nckx: I've always noticed that, but maybe I hadn't set up things? <podiki[m]>I would load the local variables/etc that emacs prompts on a Guix file, but otherwise had no gesier or other setup <nckx>Ah, it jumps to `(#:first-keyword [HERE] (stuff-on-same-line <nckx>So it's not insane, but still a regression. <nckx>How do I ‘reload’ those, if that's a thing? Because they've been enabled since $forever. <nckx>And this only started happening… this week? Maybe last? But not much longer ago. ***caleb1 is now known as Kolev
<podiki[m]>for me I never got the nice indenting behavior, but I thought it could be me (from other lisp indenting rules?) <podiki[m]>so maybe whatever caused it not to work for my by default is now more widespread? (or localized to nckx) <podiki[m]>nckx: I just tried a simple test with "emacs -Q" and loading a guix scm file, and then hitting enter after something like #:tests? #f and does the bad indent <KE0VVT>Error in finalization thread: Success <sneek>Welcome back KE0VVT, you have 1 message! ***Server sets mode: +Ccntz
<jgart>florhizome[m], hyperbola does the work of finishing up the kernel and we then get Guix to build/run on it? ;() <florhizome[m]>jgart: I think it will not be as easy as you make it sound but ... acceptable. <jgart>I didn't say it was going to be easy haha ***Server sets mode: +Ccntz
<florhizome[m]>What’s the order... run guix in kfreebsd, build a bsd module, run kfreebsd with shepherd...;) <florhizome[m]>I saw some reviews that compared guix with bsd as well as Debian, I guess that just makessense^^ <KE0VVT>Typing my LUKS password is getting old. <KE0VVT>Rebooting several times in a row. ***Server sets mode: +Ccntz
<nckx>Unfortunately currently unsolved, because it doesn't happen to anyone (a relative minority, I think) and is hard to debug even when it does. <KE0VVT>nckx: booting prev versions did not work. <KE0VVT>nckx: im special? Special bugs? Eek <KE0VVT>Guess i wont use my computer for a while <nckx>You have been chosen by the bug fairy. <nckx>I've tried to reproduce it on 3 machines (I'm not swimming in laptops like some people) + VM, no ‘luck’. <KE0VVT>Im guessing my system config doesnt help, if the error persists even when i boot #1 <nckx>I don't understand that part to be honest. <KE0VVT>nckx: im on an x200t with libreboot 2021 <nckx>It's a regression somehow introduced by the c-u-f merge, sure, but then why could you boot before? I don't know. <nckx>I don't think that matters, apart from slower machines being possibly more susceptible to such race conditions, which this appears to be. <nckx>Also don't think that matters, but who can say. Unlikely though. <KE0VVT>What info should I post to the list? Not sure how to post it from my phone <nckx>Good question. I think a ‘me too’ *is* valuable here because it could eventually expose a pattern in those affected. See if you can find one skimming that bug report (I don't have time right now, sorry). Adding details about your hardware is certainly a good idea. From what I did skim, HDDs/slower storage (maybe machines in general?) do seem to be suspiciously common in the reports. *nckx …maybe I could dig up an old HDD from somewhere, but where… <nckx>I sympathise. I used them for many years when SSDs were already the norm. Still allergic to people quipping ‘spinning rust’ or other derogatory terms. <nckx>Or ‘this is not worth fixing/optimising’. <nckx>It's a very privileged claim. <nckx>I hope it doesn't get quite as bad with NVMEs. <KE0VVT>Plus, i need cheep storage because disk clones, which i should have made before tainting my repos with c-u-f <singpolyma>I have spinning rust and and nvme both. No point wasting write cycles on the expensive drive for media and such <flatwhatson>so the chromium src tarball is 9Gb uncompressed, 7Gb is the third_party directory, 1.3Gb is third_party/llvm <flatwhatson>chromium is shipping the source code for the entire open source ecosystem <jgart>that's a lightweight chromium <mroh>maybe there is a way to throttle io in a vm to reproduce this bastard bug in a vm? <Kolev>mroh: reduce its performance to that of an x200 with hdd? *nckx seriously wondering if there's a crappy_laptop_hdd DM target in Linux… <nckx>That would be a cool one to use in a ‘does Guix still boot an X200?’ system test 😮 <Kolev>I guess i wont be able to use my computers this weekend. I'll go insane <nckx>Exposed, ya fake Amishman. <Kolev>nckx: is everybody on fancy nonfree boot firmware devices? <nckx>Genuine condolences, though. *nckx looks guilty on Coreboot. <Kolev>nckx: i only appear amish to the oppressed users <nckx>I very much doubt that *none* of the vaguely core crowd uses one… <nckx>one = Librebooted, that wasn't clear. *Kolev makes list of non computer things to do <the_tubular>Umm, just updated guix and can't login through SSH anymore :( <the_tubular>I just get connection closed as soon as I put my password in <flatwhatson>perhaps it can't run your shell, sounds a bit like when you have shell /bin/false <mroh>the_tubular: can you login via tty/console? <podiki[m]>there's been talk of just this problem here recently <the_tubular>so i doubt SSH has anything to do with it, it was just the first thing I notcied <mroh>via tty you also get the pam module error? <the_tubular>I login, screen flashes and i'm back to the login screen <mroh>could be https://issues.guix.gnu.org/52051 than. maybe try to boot an older generation and look in /var/log/debug, is there is something with "elogind is already running" than welcome to the club ;( <the_tubular>I've found a workaround: restarting elogind via SSH resolved the issue. <podiki[m]>sorry the_tubular, don't remember any conclusions if there were any, but you can search the logs <podiki[m]>seems to be some weird hard to track down bugs on login/ssh/pam (not related, probably) but hasn't affected everyone <the_tubular>Let me trying rebooting this machine, doubt it will solve anything though <Kolev>Rebooting is hard when you encrypt the disk <mroh>the_tubular: ctrl+alt+delete should still work. <the_tubular>This is going downhill real fast ... No boot device at startup ... <mroh>boot an older system generation, maybe. <mroh>yay, I think 52051 is reproducable in qemu with "throttling.iops-total=100". <the_tubular>I'm stuck in my bios, don't know what else I can try <lfam>That's great that you found a technique for reproducing 52051 mroh <lfam>Can you share it in the bug thread? <mroh>yes, will do, of course. <the_tubular>I don't know if I should get a trophy or be sad about it <lfam>The boot device was lost after a hard reset of the computer? <lfam>I think it's probably unrelated to your previous issue, the problems with logging in <lfam>Beyond that, I'm not really sure. It's been a while since I had trouble after a hard reset / power loss <the_tubular>I think so too ... I don't know who hates me that I get 2 bugs that people barely know about <lfam>I mean, it's considered risky to reset a computer, but it's been so long since it actually caused trouble for me <lfam>If I were you, I'd wait a little while for advice. There are definitely some "boot problem" experts in this channel <the_tubular>I can wait a bit, but this channel is pretty silent at this time of the night <mroh>apteryx: Im still not sure, the last try, I couldnt reproduce it, the one before did it, its weird... <singpolyma>the_tubular: have you tried repenting of any serious sins, such as use of vi or evil mode? <lfam>It may be late at night for them, if they are in Europe or Middle East <apteryx>mroh: at least we're more than one looking at the problem now :-) <singpolyma>Sorry, I know you're having an actual problem and I'm not helping 😛 <lfam>A lot of them are, for sure <apteryx>mroh: clearly a race caused by slow IO <apteryx>this only occurs on slow HD here as well <lfam>I suppose it's easier to debug than a race caused by fast IO <lfam>"throttling.iops-total=1" and `strace -f $PID1` ***theruran_ is now known as theruran
***aya is now known as gyara
<mroh>apologize for what I said while debugging! It's still not reproducable (in qemu). I wonder why it happens all the time on my real hardware, though ;( <the_tubular>So I tried reinstalling and I cant, get networking working on the installer ... <the_tubular>From a 100% working machine to one I can't even boot :/ <apteryx>the_tubular: eh, sorry to hear that. I don't get what in core-updates-frozen could have messed your bootloader though? <apteryx>OK, so you had that PAM problem, then hard reset the box, and then it couldn't read your disks? <apteryx>OK :-/. Strange. I've submitted my own box through such abuse for tens of reboots the other day (btrfs with raid), didn't get into this situation <apteryx>one time I corrupted my bootloader because I manage to get a kernel hang while attempting to reconfigure <the_tubular>Now I'm stuck though... Having problem reinstalling ... <apteryx>it it basically just couldn't load a missing GRUB module, which had not been written <the_tubular>I'm stuck at the connectivity test, It can't find the network <apteryx>one thing you could try would be to use a recent image from ci.guix.gnu.org instead of that old 1.3.0 <the_tubular>Mind giving me a link, not familiar with the UI at all <apteryx>OK, I hope it works better! good luck! <the_tubular>Should I go ahead and reinstall from scratch, or is there anything else I can try on my old partition that is apparently not bootable ? <AwesomeAdam54321>the_tubular: If you could read the disk from another machine, maybe you can find what went wrong <apteryx>you could try 'guix system reconfigure'ing after chroot'ing into your old system, if you were able to mount the old drive <the_tubular>I know networking is working with the libre kernel, it was working before everything burned <apteryx>perhaps go to tty2 (Control Alt F2) and try debugging the network there? <apteryx>probably 'ip' is there, 'ping' I guess, wget <apteryx>you can probably follow the manual installation section at this point to try to get a working network <the_tubular>Will try, damn my first day in vacation and it's going to be an all nighter reinstalling guix lol <the_tubular>My interface are up, but I still can't have an IP address apteryxà <apteryx>did you try 'dhclient -v interface' ? <apteryx>with 'interface' substituted for your interface, founable with 'ip a' <lfam>If I'm trying to convert #:make-flags to the new style, what do I do about "Unbound variable: gexp" <lfam>Yes that's normal the_tubular. That is the "broadcast address" <lfam>About my gexp question, seems I had to unquote the list <apteryx>the_tubular: do you hget addresses automatically on your local network, via DHCP usually? <apteryx>you can always try to assign yourself a static address <apteryx>but it's weird that your DHCP server is seemingly not answering to your dhcp queries <the_tubular>I've messed with lots of distros, and lots of IoTs. Never had a problem <apteryx>do you have another live USB around just for the kicks, to validate the problem relies lies with guix rather than the network? <apteryx>perhaps a minimal one where you can also exercise your networking <the_tubular>I'm pretty positive that the problem lies with guix though <apteryx>but guix was working yesterday too. the installer or the installed system has the same kernel and drivers <apteryx>hmm, I'm afraid without network working your options are limited <apteryx>so you'll have to figure out what's wrong with it first I think <apteryx>wire ethernet should just work, especially DHCP <lfam>You could manually assign an IP address from another TTY, right? <lfam>What do you mean that you can't recognize the interface *apteryx vanishes into sleep; hopes somebody else can walk you through this unfortunate string of problems <lfam>So, you are wondering which one the cable is plugged into? <the_tubular>When I pass dhclient, it comes back with an Ip adress, but it's in 129.254.x.x range <lfam>Are you sure it's not 169.254.x.x? <lfam>Sounds like it's not plugged in <lfam>`ip link show` should tell you which interface is plugged in <lfam>Or, you can try bringing them up one at a time <lfam>`ip link set $interface up` <the_tubular>Where does ip link show tell me if it's plugged in or not ? <the_tubular>All interface looks exactly the same, except for the unknown one, but one is definitely plugged in <lfam>Or use the sysfs. `cat /sys/class/net/eno*/carrier` <lfam>The interface with a cable plugged in will return "1" <lfam>Beyond that, I don't know <lfam>Maybe a missing driver or firmware <lfam>Or a bad cable or something like that <the_tubular>But as apteryx said, it was working fine just before I reboot <lfam>Yeah but then your bootloader got messed up <lfam>And since you have iDRAC, I assume it's not like a laptop but a real server <lfam>So, hardware may be configured in the bootloader <lfam>I had a similar experience <lfam>I would access the UEFI menu and look at the device manager <lfam>I don't know if that is convenient or not <lfam>But I had a similar experience. The networking interfaces did not work unless the bootloader was set up just right with firmware and everything <lfam>Somewhat mysterious to me what I needed to do <the_tubular>I've never messed with the bootloader, I didn't even knew it could impact networking interfaces <lfam>I have very little experience with UEFI but it seems that it gives access to firmware <lfam>Or it could be that the installer lacks the driver for these NICs <lfam>Were you using linux-libre on the server? <lfam>Did you look at sysfs like I suggested? <lfam>`cat /sys/class/net/eno*/carrier` The interface with a cable plugged in will return "1" <lfam>You'll need to bring the interface up, too <lfam>`ip link set $interface up` <the_tubular>Umm, so the only one that returned "1" is the one I,m not sure about ... <mala>i haven't really looked into it deeply, but i'm getting some failed builds with the new guix update -- python-esptools, pinfo, so far, should i be worried? <lfam>the_tubular: Then, that's the interface you need to use <the_tubular>Could a driver issue detect it as 0, or am I 100% positive this is the one that is plugged in ? <lfam>Try unplugging it and running the command again <lfam>mala: Somebody will have to fix those packages! <lfam>I can reproduce the failure of pinfo. I don't think we have a package named 'python-esptools' <mala>lfam, i'll take a look -- tbh i was worried that it was a more widespread issue, but i don't seem to have had any more issues since <mala>lfam, sorry python-esptool <mala>a bit of a rough merge this time around! <lfam>It's always kind of rough <the_tubular>So I unplugged idrac, cat the unknow interface, still 1 <lfam>mala: We invite people to help with core-updates but not every single thing gets checked. Not as many people assist as would be ideal <the_tubular>So I unplugged the only interface left (that is suppose to be eno1) still 1 <the_tubular>So without any RJ45 plugged in, it still answers 1 ... <mala>lfam, yep, i tried switching to the core-updates branch early to help check it out, but it was a bit overwhelming <lfam>It can definitely be overwhelming <lfam>I don't know the_tubular, I've never used it before. <lfam>mala, florhizome[m]: The best way to get these packages fixed is 1) send a patch to fix them or 2) file a bug report about them at <bug-guix@gnu.org> <lfam>the_tubular: It sounds like the Guix installer doesn't support your system <the_tubular>I'll just ask my first question, why is it not supported on the installer but supported on the system itself ? <lfam>Are you still using the 1.3.0 installer? *mala belatedly realises he can just --do-not-upgrade packages that don't build right now <lfam>The latest one? Yes, it's worth a try, but not tested <lfam>As for the kernel, I don't know if it's the same. Like, what kernel did you have installed, and which one are you using now? There is also the question of what firmware the installer provides. Maybe it is different from your config.scm. And then like I suggested, if your UEFI bootloader is not working right, your hardware might not work either <lfam>Earlier you said that your computer didn't boot <the_tubular>Yes, when I rebooted it said that no bootable partition was found on the device <lfam>UEFI stands for "Unified Extensible Firmware Interface". It is the thing that handles firmware <lfam>Since this computer is a server, you probably need some special firmware for your NICs <lfam>It's unlikely that the Guix installer has this firmware <lfam>If you know what model of NIC you have, then you can find out what firmware it needs <lfam>I hope that somebody can help you fix it. I don't know enough about UEFI to help <the_tubular>I could maybe boot debian live CD, install guix on it and run my config.scm ... <the_tubular>Altough I'll certaintly run into more issues though, I don't know If I'm able to convert debian into guix <lfam>Do you know what model of NIC you have? <lfam>the_tubular: `lspci` and look for the network interface <the_tubular>Sorry was in my server room testing stuff, still no progress <bdju>my swaylock takes several seconds to disappear after a successful password entry since my recent updates. did anyone else run into that? maybe it would be better after a reboot or sway session restart or something. <the_tubular>I finally got an IP adress, but it's still not working ...! <the_tubular>Interface is up, I have a local IP, still can't ping 8.8.8.8 <fiesh>run tcpdump on the devices inbetween to see what happens to your packets <fiesh>and isolate the first point where either the ping request or the ping reply ceases to exist <the_tubular>I have an IP in my range, same range as I'm talking on IRC right now, but I can't ping anything ... <fiesh>I don't know what you mean by "IP in my range" -- do you own a public subnet? <fiesh>so your device is assigned a local IP address... can you ping the default router? can you access it by means other than ping, say via TCP? <fiesh>then I'd again recommend running tcpdump on your router, possibly both on the internal and the external device, and see what happens to your packets <fiesh>(assuming the host does not feature a misconfigured iptables or the likes and has its default route set correctly) <the_tubular>I mean I can send packet to my router, but nothing else on my network <jpoiret>the_tubular: what does ip route say? <jpoiret>it should have a line that looks like "default via x.x.x.x" <the_tubular>Never really used that command though, I'm not totally sure what am I looking at <jpoiret>that means you don't have a default route, so packets don't know where to go, although you are connected to the network <jpoiret>does that router have a dhcp server? <jpoiret>then did you run `dhclient <interface>`? <the_tubular>I mean that command gave me an IP address, that I didn't have before <jpoiret>so your DHCP server doesn't assign a default gateway i'd say <jpoiret>i'd say do "ip route add default via x.x.x.x" where the IP is your gateway <jpoiret>and `ip route` doesn't say anything about a default route? <the_tubular>There's one default line, but it's not on the good itnerface *the_tubular installs guix harder before ragequitting <the_tubular>I'm getting disk UUID not found you may need to reformat <jpoiret>the_tubular: formatting the disk or the individual partitions? <jpoiret>i'd run cfdisk /dev/sdX (or whatever your block device is) to see if the partition table is okay, if so, you can reformat a partition using mkfs.TYPE /dev/sdXN, where TYPE is the filesystem type, and N is the partition number <jpoiret>be careful, double check everything as that will erase the contents of the partition <jpoiret>you can also do `mkfs.TYPE --help` first as each fs has its own options <jpoiret>did you mount any of the partitions? <jpoiret>ah, don't try to reformat the device you're running from <the_tubular>And the installer is complaining about /dev/sdb for some reason <jpoiret>oh. Are you using a recent installer? ***irfus- is now known as irfus
<jpoiret>the_tubular: what kind of device is your iso booted from? Does the installer list /dev/sdb when it lists the devices available to format? <jpoiret>the_tubular: when you downloaded the installer, did you download latest or stable? <the_tubular>I had trouble with my network for a few hours, so I tested both installer <the_tubular>Is there something wrong with my usb stick be on the available lists to format jpoiret ? <jpoiret>yes, the installer shouldn't list it here. It doesn't think it's the installation device, so it will wait on it to be available later on. That might be an installer bug, let me try to reproduce it in qemu. <jpoiret>uhm, where did you download the installer? <jpoiret>oh no I got it, latest is a separate page <the_tubular>Is the installer still being work on ? I've installed guix on like 2-3 machines and every time I had a different bug ***lprndn- is now known as lprndn
<jpoiret>you shouldn't need to use it, only `dd if=the.iso,of=/dev/sdb` <jpoiret>so then, can you tell me what /proc/cmdline looks like? <jpoiret>but only look at the --root parameter <jpoiret>can you find the same numbers in /dev/disk/by-uuid/? <jpoiret>if so, when you `ls -l` that directory, what does it point to? <jpoiret>i'd say, try burning the whole iso to the usb drive using `dd if=the.iso of=/dev/sdb status=progress` first <the_tubular>It was erroring but it was with the 1.3.0, not the one I linked to you <jpoiret>can you try with the latest installer? The 1.3 stable is (notoriously) broken <jpoiret>one of the goals of 1.4 is to have a working stable installer :) <the_tubular>I could try with "latest" but that machine is the only one with dd :/ <the_tubular>Are you sure that's where the bug comes from, or is there something more obvious I should check first ? <jpoiret>I use Rufus on windows, has always worked for me <jpoiret>the_tubular: well, if the bootloader reports an incorrect root device, the installer won't be able to know which one it's running from <jpoiret>although we could add another check, but we generally trust the --root parameter to be correct <jpoiret>can you check again using `lsblk -o PATH,UUID` that the UUID is not present? <the_tubular>I can't find which disks is referring to the --root parameter <the_tubular>Nope, i did that and the number from the --root parameter is still missing <jpoiret>i think ventoy does something we don't expect <the_tubular>Ironically, my first install was on 1.3.0 with Ventoy <the_tubular>But yeah, I'm still unsure which UUID is after the --root parameter <the_tubular>But that disks has nothing to do with guix yet, it's part of a ZFS pool <jpoiret>ventoy doesn't really document how it boots linux isos <jpoiret>emulating a USB drive using QEMU gives me the expected result <jpoiret>so i'm pretty sure it's a ventoy issue <jpoiret>I think that's how you'd maximize your chances :) <jgart>civodul, > But the tools are our disposal are not capable enough for this application. <jgart>civodul, > But the tools <at> our disposal are not capable enough for this application. <jgart>civodul, just catching a typo <jgart>civodul, > design an implement the missing pieces <jgart>civodul, > design <and> implement the missing pieces <PotentialUser-12>Hello everyone. I am new to Guix and am currently trying it from the QEMU virtual machine file provided on guix.gnu.org. First of all, I would like to thank everyone who contributed to this amazing piece of software! <PotentialUser-12>In order to try Guix, I tried to reconfigure my (virtual) system by changing its hostname. I therefore copied /run/current-system/configuration.scm to another location (let's say ~), modified the hostname field in the file, then run sudo guix system reconfigure ~/configuration.scm. Everything seems to run normally. Then I reboot my system, and <PotentialUser-12>instead of booting up to the connection screen then to XFCE, a "Bourne-like REPL" starts and I don't know what to do from there. <PotentialUser-12>Anyone knows what is going on? Sorry if this is a stupid question, but I'm very new to Guix and I really wanna learn more about it! <abrenon>do I understand correctly that you reconfigured the VM image itself, you didn't try to install inside a VM ? <jpoiret>PotentialUser-12: Are you using a qcow2 disk image, or the ISO? also, is qemu using EFI or Legacy boot? <PotentialUser-12>jpoiret: yes, I use the qcow2 image downloaded from the website. And I don't know if qemu is using EFI or Legacy boot, sorry <jpoiret>are you running qemu from the command line? If so, unless you're using the -bios option with a firmware, it's running in legacy boot <abrenon>I don't think it should, but that's something I haven't tried myself, and since I see no obvious reason why what you have tried shouldn't have worked on a "regular" system, I can't help wanting it to be linked to the issue : ) <jpoiret>is the shell you're presented with the GRUB rescue shell? <jpoiret>it should be pretty visible if that's the case, you won't miss it <abrenon>you didn't get any message about GRUB during the reconfigure ? so I take it that you passed -drive with format=qcow2, otherwise QEMU would've complained about not being able to write to the first sectors <jpoiret>abrenon: the manual doesn't include running it with format=qcow2, maybe that's the issue <jpoiret>although I don't think it should matter, as the older GRUB should work just as well if it wasn't able to update the MBR-installed one <abrenon>running, it, no, but if you want to reconfigure it, GRUB's got to be able to write to the first sectors, and I know that's a frequent issue I've had when I booted VMs without specifying the format of the drive <PotentialUser-12>Well, when the system starts, I can choose between my newly configured system or the previous generation. Then I boot the new generation, I get the REPL, but the old generation still works properly. So I don't think it's an issue with GRUB, but I might be wrong <abrenon>but there should've been messages from GRUB during the install, in that case, I think <jpoiret>PotentialUser-12: can you see any error messages above the REPL? <PotentialUser-12>I don't remember seeing any message from GRUB during the reconfigure, but I might have missed them <abrenon>when does the REPL appears ? how long after selecting the new generation ? do you get the regular boot steps that you get with the old generation ? <PotentialUser-12>jpoiret: yes I do, sorry, I might have started from this! Let me try to send a screenshot <PotentialUser-12>By the way, would it be preferred to run Guix by installing it from the ISO file? <jpoiret>and you say that the older generation boots properly? seems weird to me <abrenon>how did the filesystem ever managed to get corrupted ? (but still be fine when you boot from an older generation ^^) <PotentialUser-12>I tried to look it up on issues.guix.gnu.org but couldn't find anything that matched. And I tried to do that twice from a fresh download of the image and obtained the same result twice. Also I ran guix pull before guix reconfigure, I don't know if it matters <jpoiret>can you try again by adding format=qcow2 to the -drive parameter as abrenon suggested? <phf-1>jpoiret: Well, let's hope it will get fixed. Thank in advance to whoever manage to do it. <jpoiret>phf-1: it looks like a Debian packaging issue to me but I might be wrong <abrenon>PotentialUser-12: the whole syntax looks like: -drive file=/path/to/the/guix/image.qcow2,format=gcow2 <PotentialUser-12>Alright, I will try adding format=qcow2. Thank you very much jpoiret and abrenon for your answers! <jpoiret>packages.debian.org doesn't load for me <PotentialUser-12>Adding format=qcow2 does not seem to help. I will try to reconfigure the system with that option enabled <abrenon>if that is the cause, it simply explains why reconfiguring could've worked less well than you originally thought it had <jpoiret>phf-1: do you source the guix profile in your .profile? <jpoiret>did you `guix pull` before reconfiguring PotentialUser-12 ? <jpoiret>phf-1: can you add `export XDG_DATA_DIRS=/usr/local/share/:/usr/share/` right before sourcing the Guix profile, and retry? <abrenon>PotentialUser-12: and you didn't edit anything except the (host-name …) field ? <jpoiret>do you use the virtio-blk device as described in the manual? <jpoiret>can you please try instead `qemu-... -m 4096 -smp 4 -enable-kvm -hda path-to-the-image.qcow2`? first two arguments are just "use 4096 MiB memory, 4 cores" <jpoiret>it's entirely possible that the installation image has an outdated/broken virtio-blk driver <jpoiret>phf-1: great! i was pretty confident it was going to work <jpoiret>the idea is: the XDG specification says that if XDG_DATA_DIRS is unset, a default value of `/usr/local/share/:/usr/share/` should be used. <phf-1>jpoiret: Well, thank you very much. How would you have debugged it? <jpoiret>but then, if XDG_DATA_DIRS is unset and we prepend to it, `/usr/local/share/:/usr/share/` disappears <lprndn>Trying to cross-compile glib for aarch64 I get 'unbound variable: %outputs'. I suppose it needs to be converted to the new style (with gexps), right? <jpoiret>so here, you just force the env var to be set to its default value <jpoiret>phf-1: you could link the issue URL in your comment, to have the fuller picture :) i am going to send a follow-up email, and maybe some more discussion will spring up in the future <PotentialUser-12>jpoiret: thank you very much for the suggestion. Now when I run guix system reconfigure, I get error: device '/dev/vda1' not found: no such file or directory. I think I might have to edit something in configuration.scm <abrenon>well probably the (device …) fields in the file-systems <jpoiret>you should definitely use partition UUIDs instead of /dev/vda1 though <abrenon>what are your actual devices called when you boot from the old generation ? sudo blkid ? <PotentialUser-12>I get /dev/sda1 and /dev/sda2. I'll try switching to partition UUIDs as suggested by jpoiret <jpoiret>the fun part is that when doing `qemu system image -t qcow2 xyz.scm`, the root device definition is not used for the installation, but rather a fixed partition UUID that the installer is able to generate <abrenon>hmmm we should've thought directly about it with the log message about /dev/vda1 <jpoiret>oh, but when running with the virtio-blk drivers, i think the devices are actually called that. Just that the driver might be broken, so better fall back to good old QEMU HDD emulation <jpoiret>if it works for you PotentialUser-12, we could update the documentation (or find out the root cause! fun times) <abrenon>ohhhh I missed the instruction line, I didn't even know about virtio-blk in QEMU <abrenon>I thought one *had* to revert to "-hda mode" once the image was generated to modify it <jpoiret>PotentialUser-12: are you on a big endian architecture per chance? <jpoiret>looks like virtio-blk is pretty unstable <jpoiret>abrenon: iirc only the format=raw needs to be specified because raw autodetection is disabled, qcow2 shouldn't need it <PotentialUser-12>Thank you very much one again jpoiret and abrenon for your kind help! I have to take a break now, I'll be back soon. Cheers! <abrenon>jpoiret: hmmm, I must be using raw drives to often, I thought the message appeared with both, thanks ! <jpoiret>it doesn't hurt to use it though! it's just that I often use -hda and it doesn't let you specify that, so I guess it works without it <jgart>civodul, wdyt of a `guix fmt` command so that non emacs users don't have to install emacs and run `indent-code.el`. Instead, the indent code script is built into guix. <jgart>civodul, Maybe this should be part of guile? <jgart>civodul, `guix fmt -L /path/to/channel my-package1 my-package2 …` <abrenon>adding a subcommand raises the perceived complexity of the tool <abrenon>having emacs 'installed' isn't really a problem on a system like guix where you can simply get an environment with it "for free" when you need it <abrenon>I say this as an absolute ignorant of the ways of emacs, I never use it, don't know a single shortcut, and I simply see it as a development dependence for guix, including emacs or coreutils when I work on the repos doesn't make a big difference for me <jgart>It just feels cleaner for users to run `guix fmt ...` than having to open emacs when they don't use emacs. Imagine telling a rust user that the standard way to format rust code is with an emacs lisp script instead of just using cargo's built in `cargo fmt`. <jgart>Same gos for crystal, golang, etc... <jgart>most modern tooling is starting to include the code formatter in the cli tool <abrenon>but not sure exactly what you mean by "open emacs", it's simply the "interpreter" for the ident-code.el script <cybersyn>jgart: +1 for "guix fmt" being nice. I'm an emacs user but its something I also thought about. The issue being I think (but haven't looked) there is some inheritance from emacs to do the magic. <jgart>I currently use `indent-code.el` and have it vendored into my bin/ scripts in my dotfiles <jgart>I use it with a headless emacs <jgart>and a new user is not going to do that <jgart>it's not beginner friendly and beginner's are actually the one's who most need indent.el <jgart>I use emacs also when the occasion arises <jgart>I call it `guix-indent-code` <abrenon>I think I still register as a beginner (at least for guix), and calling the script didn't upset me, it was just part of the routine of checks to perform before generating the patch <jgart>But imagine if a new user just needs to do `guix fmt -L /path/to/channel my-package` <jgart>They don't have to worry about learning how to run an elisp script :) <cybersyn>while guix is an emacs-centric distro, I know some very involved contributors are not emacs users, and I think plenty of vim users who would be drawn to Guix because they see the benefits of scheme will be turned off by having to download emacs, because that crowd tends to prize minimalism quite strictly <jgart>They just have to learn how to use one tool: guix <abrenon>emacs script.el wasn't that hard but I still like you argument about the "expected" option when compared to the other packaging suites <jgart>I think we should make all editors first class citizens in Guix ;() <jlicht>But perhaps as part of guix style, rather than as a separate command? It seems functionally adjacent to me, at least <abrenon>again, I don't think "minimalism" can be evaluated as on any other distro <jgart>I personally use vis mostly not vim or neovim but nonetheless <abrenon>with tens of Gb used for /gnu/store as soon as you install anything <abrenon>having one or two copies of emacs in there isn't a big deal, even for a die-hard vimmer <cybersyn>I saw fennel + nvim recently. reminds me how amazing guile-emacs could be :) <the_tubular>I get a patch not found at the very end of the installation <jgart>Zepheir was working on rebuilding parts of the core of vis with chibi scheme <cybersyn>I started importing my org docs into TexMacs for final touches recently so that I can check out Guile's integration with it -- and highly recommend checking it out, its pretty amazign <jpoiret>oh. That seems like a proper issue. Let me try debugging it here the_tubular <cybersyn>jgart: wow thats amazing. is it online? would love to check it out <jgart>cybersyn, It was online in a fossil repo <jgart>I might have a copy lying around somewhere <jgart>or you could ask Zepheir for it on #scheme <jgart>Zepheir sent it to me through email <jpoiret>the_tubular: are you using the graphical installer? <jpoiret>by that, I meant that this issue looks like it is 100% guix's fault <the_tubular>I got to the very end, edited a bit of the file it gave you and ran it <jpoiret>not to say it would have been yours, but sometimes hardware is finnicky for example <jpoiret>what exactly did you edit in the configuration file the_tubular? <jpoiret>i'm building guix on my side, since that seems to be the issue <the_tubular>removed, xorg, cups, and another desktop module I forgot <jpoiret>alright, nothing out of the ordinary then <jpoiret>it'll require a patch on our side though <jpoiret>the patch you're mentioning isn't registered in our local.mk file, so isn't included in the final guix output <jpoiret>a long time, although the issue should've popped on master about 5 days ago <the_tubular>Is there a way to just rerun from where I was in the installer or I need to go from the beggining ? <jgart>thnx! :) Feel free to take anything for your own configs. That's what I do <civodul>jgart: yes, i think "guix style" could replace indent-code.el <civodul>(it could have been "guix format", but not "guix fmt" ;-)) <jpoiret>civodul: do you know if the installer tries to guix pull before installing? <jpoiret>or does it use its own bundled guix copy <jpoiret>civodul: we're missing gcc 10 patches in local.mk, and so the current installer cannot `guix system init` at the end of the install process <jpoiret>I have a patch coming that adds all missing patches to local.mk <the_tubular>Does that mean I have to burn another iso on my usb ? <jpoiret>you could do the manual installation process but `guix pull` and use the new guix manually <jpoiret>civodul: if patches aren't included in local.mk, are they still present when guix pulling? that's what i've been wondering, because we haven't hit that issue ourselves <jpoiret>that also means that we need to update the guix package to after this patch, otherwise all installers will not have that gcc patch <the_tubular>I see, my plan was to include the config in my guix home later <the_tubular>I'm not sure I understand what you mean, jpoiret, could I just guix pull and run the graphic installer again ? <jpoiret>the installer uses the guix it was created with <jpoiret>guix pull would 1) get the newest guix in your store 2) update your $HOME/.config/guix/current/ to point to it <jpoiret>but the installer doesn't use .config/guix/current/ <the_tubular>Yeah, might just go take a nap, been on this for a while and redownload the iso tomorrow <civodul>jpoiret: yes; "guix pull" uses (guix self), which doesn't rely on local.mk to find patches <vldn[m]>possibly related, what paths are needed to added to bashrc? i tend to overwrite it with my custom definition on my systems and recognized that somethings like progs installed with nixs are stop working because of fontconfig and something.. <jpoiret>vldn[m]: you only need to source the guix profile's /etc/profile, so for the default one just source ~/.guix-profile/etc/profile <vldn[m]>i'm using the "--profile" options with guix pull on /usr/guix to use the same profile on my single user guix installation <the_tubular>How long until there's a new installer that is going to be fixed jpoiret ? <jpoiret>the_tubular: well, we'd need first to add 2 commits to master, and wait for CI to build it again <jpoiret>but, at this point, you're almost done with the installation <jpoiret>you only need to guix pull, and use the new guix to `guix system init /mnt config.scm` <jpoiret>although I don't know where you'd get the installer's config.scm, it might hang around in /tmp or in /root <jpoiret>ehm. What's the error (right after the backtrace)? <jpoiret>yeah, looks like a proper bug as well... <jpoiret>i'd say, wait for the next installer image <the_tubular>I'll go take a nap, you think it'll be good in 5-6 hours ? <NicholasvonKlitz>I submitted a patch to add gtk-rs for gtk4 on Wednesday but haven't heard any feedback so far. What's the usual timeline for reviewing patches and is there anything I can do to support the process? <rekado_>NicholasvonKlitz: could you tell us the issue number here? <rekado_>I can’t review this now, but maybe someone here has time now <singpolyma>NicholasvonKlitz: I've been sold not to consider a patch stale until at least two weeks. Sometimes longer *rekado_ successfully built icedtea 2 without first building icedtea 1. <NicholasvonKlitz>It's not high-priority. I just want to better understand the review process. <rekado_>NicholasvonKlitz: the process is … a little overstretched, I’m afraid. <rekado_>I’m not familiar with rust so I probably wouldn’t attempt to review it under normal circumstances. <rekado_>(I keep busy with R and bioinfo packages, mainly) <NicholasvonKlitz>Now, I have patches to ad libadwaita-rs which obviously is dependent on my patches for gtk4-rs. What's the best way to process here? <apteryx>you can specify dependencies in debbugs <rekado_>or you can send your patches as a series <roptat>it's one for ipv4 and one for ipv6 <apteryx>I think so; multicast is typically enabled on most network IIRC (thus taken for granted) <mothacehe>maybe that should even be the default in guile-netlink (link-set procedure). <mothacehe>more exactly link set should have the same default flags as "ip link" <apteryx>mroh: can't seem to reproduce with low iops and bps values passed to the '-drive' argument of a 'guix system vm' produced script (e.g., iops=10 or bps=100000) <apteryx>mroh: what kind of image/script were you using? I'm using the gnu/system/examples/vm-image.tmpl template <lfam>Does anyone have a good example of a package that wraps its shell script with its dependencies? <lfam>I'm talking about a package that would use the wrap-program procedure <vivien>I tried to use wrap-program for openresolv, but civodul suggested to just substitute the installed script so that it’s more straightforward. <apteryx>lfam: emacs is wrapped this way (not a shell script, but does it matter?) <lfam>I want to show a new contributor how to do it, so I'd prefer the most straightforward example <singpolyma>If it's actually a shell script there is also wrap-script <lfam>Oh, that sounds like the right thing <apteryx>civodul: was there anything that needed fixing on master for the next release but would trigger a big rebuild? <apteryx>I have this sitecustomize.py patch ready; but it'd be nice to batch it with something else if there is <vivien>lfam, you should go with wrap-program, that’s the most generic one and it will work in many situations <lfam>apteryx: I am not civodul, but it would be nice to fix #52483 "for real" <vivien>(it’s the best investment to learn for a newcomer) <rekado_>apteryx: there’s also a suspected bug in wrap-script <lfam>apteryx: What I've done makes it possible for anyone to get the fixed GnuPG, but it would be good to fix it for all uses <lfam>I mean, what I did in my patch <lfam>There is actually a new major version (2.3) but that sounds like a risky update for this time <apteryx>mothacehe: I've seen the 'deactive' option on specifications in cuirass, cool! How can I turn it back on though? <mothacehe>apteryx: thanks, there's no graphical way for now, only the sql method <mothacehe>there's a boolean in the specification table <apteryx>it's not for now; I've deactivate the version-1.4.0 branch in cuirass. I'll recreate it, amass large rebuilding changes on it, and when ready, reactivate it in cuirass <apteryx>Perhaps you can share the query to use in case you aren't there when the time comes to reactivate it? <lfam>I have another question. Does anyone have a example of a wrap-program in the new style? *apteryx recreated version-1.4.0 from current master (there was nothing on it) <mothacehe> apteryx: sure, the query would be: update specifications set is_active = 1 where name = 'version-1.4.0'; <apteryx>the version-1.4.0 now has the sitecustomize.py bug fix; it won't be built until we run the above query (let's batches more changes before we do so!) <mroh>apteryx: I used an image which I also use for testing xfce changes/upgrades/etc. I tried with several iops down to 1, but no luck. (polkit runs in timeout, but this seems harmless). <apteryx>mroh: it's really tricky to reproduce, to the point it seems a better time investment to review the outputs currently gathered and read dbus/elogind sources. <mroh>yes, I'm not sure anymore that it depends on slow io. <apteryx>so far civodul had mentioned that stracing the dbus-daemon may provide more clues to understand why it fails with "Failed to read credentials" <apteryx>I should do this, but rebooting my main desktop is a real productivity killer <mroh>apteryx: yeah. I have this issue on my main desktop machine, but never saw "Failed to read credentials" (in a logfile). <civodul>mothacehe: re multicast yes, though we can do it by adding a 'multicast?' field <mroh>and it's 100% reproducable there (so far)... <rekado_>as a side-effect of rebuilding icedtea@2 its closure is now down to 298.2MiB (from 564.0MiB). We just do without gtk+. <apteryx>zimoun: yes, and it was discussed here recently. My personal opinion still goes 1.4 (which APIs did we break?), but if there are good arguments for a 2.0 I'm all ears. <mothacehe>civodul: ok thanks, i'll work on a patch for that <apteryx>mroh: you need to enable verbose mode on dbus (with a specially built dbus...) to see it <apteryx>if you review the many messages of the bug, you'll find a xz compressed file corresponding to it <apteryx>should you want to use it, I can also merge my change to the dbus service that enables doing so easily <apteryx>mroh: yes, 100% reproducible on an actual reboot of my main HDD-equipped machine. It's quite frustrating. <zimoun>apteryx, because backward compatibility care, nothing break never, so we will never release 2.0 ;-) <roptat>mothacehe, I can have a look to make it default <mothacehe>roptat: would be nice, on guix side i'll add mtu and multicast properties as suggested by civodul <roptat>I'll be busy today but I might find some time this weekend to figure out the actual defaults from iproute2 <civodul>(or should it be 'maximum-transmission-unit'?) <rekado_>bah, looks like I really do need gtk in order to build the *next* icedtea. <jpoiret>apteryx: did you see my reply yesterday for the issue? <jpoiret>I think that the Failed to read credentials is not the root of the issue <rekado_>I meant icedtea@2 needs to be built with gtk2 so that it contains modules that are needed to build icedtea@3. <civodul>i was asking because gtk 4 depends on Rust and whatnot, so it would have create a bigger ball of spaghetti <lfam>Seems incredible that GTK would depend on Qt <lfam>I agree we should do surgery on the graph <apteryx>also a telling reply from a #gtk dev when I reported that even GTK depended on Qt in GNOME: "* mclasen doesn't care". Coolio. <lfam>I hope our channel can hold itself to a higher standard of communication <lfam>There's plenty of things I don't care about but it's important to communicate in a more cordial way <podiki[m]>gtk and qt together??? what's next, dogs and cats living together....mass hysteria! <kwjc1>simpler is always better imo <lfam>It's not a big deal conceptually. It just complicates things for a project like Guix that models packages in a graph <lfam>And does seem a bit odd, since these two toolkits are basically in competition <lfam>But, nobody pays attention to this kind of thing because it usually does not matter <civodul>apteryx: re gtk -> qt, yeah, i remember reading your bug report, and the reaction you got on #gtk isn't... empathetic <lfam>Like, it's fine if they consider it to not be a problem. But there are better ways to communicate that <apteryx>it's fixable though; so I get the reply as "doesn't care about packaging specifics"; which seems typical of software developers (which may explains things like cargo). <lfam>I mean, that point of view makes sense. Writing a program is a different endeavour than deploying and integrating it <roptat>vagrantc, ah nevermind I just read the user tried that already <attila_lendvai>when is it useful to serialize a config object? context: define-configuration <civodul>mothacehe, roptat: BTW, i had a bug earlier where i fogot to specify a subnet mask in (network-address ...), so i ended up as if i had given "/0" <civodul>should we detect that at reconfigure time and error out? <civodul>i suppose there's no use case for "/0", is there? <mothacehe>yup we definitely want to catch that one i think <civodul>"ip r add ..." would fail with an obscure message, so it could me a while to figure it out <mbakke>civodul: I think /32 is a reasonable default if not specified <mbakke>that's what the ip command does, anyway <mothacehe>we may also want to extend the static network interface system tests as this is a somehow critical service <jonsger>%build-inputs got dropped with the c-u-f merge and needed to be replaced with those "Gothic" sexp/gexp thingy? <attila_lendvai>oh, re serialize and define-configuration: this is basically just a way to emit it as a string, not a serialize/deserialize infrastructure. <jackhill>civodul: btw (not sure if you say my message a few days ago), but my static networking problem was that a copy-pasted a space after the address/netmask, which I guess got passwd happily to the kernel <zimoun>civodul, thanks for “guix hash”. <lfam>apteryx: If you want, I can do some testing of a gnupg upgrade for version-1.4.0 <lfam>I want to make a backup of the datefudge source code, which has been deleted upstream. In Guix, we apply a patch to this source code, so I can't log on to berlin and do `guix build -S datefudge` to access to the tarball named by the hash <lfam>What is the best way to find the file for preservation? <lfam>Hm, I guess I could try building without the patch :) <nckx>lfam: I just search for the tarball and check the hash. <apteryx>lfam: yes, please (I'm fine with testing an upgrade) <lfam>I remember you gave me a tarball but it had a different hash <nckx>Yeah, that was the patched version. <nckx>I was a bit distracted that night :) <lfam>I'm going to put it on archive.org and add the URI to the package definition <lfam>(Unless we have a better option for tarballs currently) <lfam>Datefudge is a dependency of gnupg so I'd like to take extra care that the sources are available <nckx>That would also be my suggested (and own) workflow. Happy to hear if there's a better one now that archiving has become more of a thing. <zimoun>lfam, not yet because it is tar.xz. If it was tax.gz, Disarchive+SWH would be an option :-) <lfam>Soon enough, I am sure :) <nckx>Yes, xz is being worked on. <nckx>Oh, and I forgot: good morning Guix. <singpolyma>lfam, zimoun: couldn't you just recompress and then submit to SWH? <lfam>Would it still match the hash specified in the package definition, singpolyma? <singpolyma>lfam: you would change the package definition I assume <lfam>My goal is to keep existing code working <nckx>singpolyma: We could, to preserve the code itself, but that's not really the point. <nckx>It would be great if some day guix time-machine can just be assumed to keep working ‘forever’. <nckx>It doesn't if past hashes no longer match. <lfam>We had a problem the other night when our build farm was offline. It was no longer possible to build gnupg from source <singpolyma>Probably want to not include URIs to malleable non-archive sources in the first place then, right? <lfam>Not sure I understand your suggestion <lfam>Every Guix package has a URL that fetches from upstream, which is rarely an archival source <lfam>It's weird that Debian deleted this tarball from their servers, but here we are <zimoun>the issue is not URI, it is checksum in the Git tree. <singpolyma>lfam: right. And often from upstreams that aren't even git or other content addressable <nckx>URLs aren't the problem. They work great. It's that we don't have content-addressed fallbacks resistant to one (!) node going down. <nckx>Using NIHURLS would be a step back, not forward, IMO. <singpolyma>nckx: right, but using always git refs would mean SWH fallback works, for instance <lfam>I've long wondered if it's possible to arbitrarily add things to the Nix content-addressed archive <singpolyma>Every time I add another rubygems or pypi url to a guix package def I feel dirty <lfam>I would trust those to stay online for a loooong time. Pypi at least <singpolyma>lfam: maybe. Does pypi not allow authors to retract a version? <nckx>singpolyma: We already gravitate towards using git-fetch over url-fetch nowadays compared to ~5 years ago. But the fact that SWH is currently biased towards git is an implementation detail. <singpolyma>nckx: sure, doesn't have to be git, just can't be tarball-over-http <zimoun>singpolyma: the issue is intrinsic content-address (as Git) vs extrinsic as tarball+URL. <nckx>zimoun: Some NIH invented ‘permanent’ URL scheme 😉 because I don't think the suggestion to ‘not include non-archived URLs’ indentifies or solves the real problem. It's confusing URLs with content-addressability, which we *already have*. <zimoun>nckx: NIH = National Institutes of Health? <nckx>raghavgururajan: Since c-u-f, yes. <lfam>I'm guessing that we will have similar issues with all Debian tarballs. My guess is that they don't preserve tarballs that are not used in a release <nckx>This was surprising to me when I looked at the datefudge URL yes. <raghavgururajan>nckx: I see. Can I delete that phase if its looking for a module that is not present? <lfam>The issues with this particular tarballs are that 1) SWH does not handle this tar format yet and 2) Nix did not use this package. So there was no content-addressed fallback to use <nckx>I wonder if we could fall back to web.archive.org/*/-style URLs automatically? <lfam>I think that archive.org embeds the upload date nckx :/ <lfam>I mean, embed it in the URL <nckx>Sorry, the ‘*’ was literal, that was not clear. <lfam>Anyways, we *do* have our own content-addressed fallback, but since our server was offline, it could not work <nckx>lfam: ‘*’ means ‘give me any (presumably latest but I didn't check) archived date’ but I don't know if they support it everywhere. <zimoun>nckx: yes, civodul proposed that. But as lfam said, it requires dates. <nckx>It would still break if the last archive was a bogus 200 or redirect rather than 404. <nckx>So * doesn't always work? <lfam>Can you glob a URL like that? <lfam>Sure. I'd say we should ask archive.org before we deploy it, but otherwise I don't see any downsides <nckx>raghavgururajan: I'm not sure myself, yet. I ran into the same problem (sanity-check dying because a module ‘wasn't found’ that wasn't an input) but the actual code is written in Python, which I can't read. <nckx>lfam: Right, my only caveat was going to be ‘but it might be computationally expensive on their side’ so I agree! <lfam>I mean, ideally our code wouldn't exercise it very often <lfam>Still a good idea to ask <nckx>It wasn't a well-fleshed-out suggestion, just something that came to mind with singpolyma's suggestion (thanks!) <raghavgururajan>nckx: I see. gajim's 'sanity-check phase fails because the phase tries to import gajim_remote, which is not an actual module. <nckx>See, now we're getting into ‘Python, I do not speak it’ territory ☺ <nckx>I can bluff my way through it when most of the surrounding code is Guile but this isn't. <nckx>raghavgururajan: I trust your opinion on Gajim. <nckx>People shouldn't disable the phase just because it seems annoying but this seems like it's a genuine over-dependency? <nckx>Or, not even a module, whatever that means. <nckx>This is the point where I usually spot the obvious and now public typo but I'm not seeing it. *lfam pushes an archive.org backup URI <tex_milan>Hi Guix. After latest update I got interesting issue with i3 and its bar. After start it shows really big font there. After <Shift-Win-R> (reload configuration) it gets the correct size. Any idea what to look for? <PurpleSym>raghavgururajan: Wrt gajim: Can you post the full message of the 'sanity-check phase? Usually it’s better to patch setup.py, but on rare occasions it’s acceptable to disable that phase. (Author of the 'sanity-check phase here) <lfam>tex_milan: If I understand correctly, shift-win-r actually restarts i3, not just reloading the configuration <lfam>That's what the manual says, anyways <lfam>It doesn't answer your question but might help clarify things <nckx>That doesn't mean it's not the same problem. <lfam>Another candidate for version-1.4.0, apteryx: #52519 <tex_milan>yep, you are correct. just reloading-configuration <Shift-Win-C> does not affect font size. It needs to restart i3 with <Shift-Wind-R>. <lfam>Well I guess it helps narrow it down, if you can figure out what the difference is in practice <jacereda>Hi, is there something like nix flakes for guix? <nckx>They sound like (one of?) Nix's version of channels. Although they are sandboxed, which channels are not. And Guix also doesn't have a concept of ‘modules’ like Nix has. <apteryx>rekado_: re 40039, does the patch Brendan proposed look good to you? <jgart>How can I run a custom guix channel off of core-updates branch? <nckx>What exactly do you mean by ‘run off of’? <jgart>For example, to say that I want all the packages in a guix channel to only use inputs from core-updates branch <nckx>jgart: See Info: (guix)Declaring Channel Dependencies <nckx>I wonder how it will fare with 2 different branches of the same repo. You 'bout to find out. <jgart>not to self: (branch "core-updates") <jgart>cool, that seems simple enough <nckx>You can also use that in ~/.config/guix/channels.scm to make ‘guix pull’ always use core-updates which is why I asked what you meant. <jgart>nckx, but I also want it to track master <jgart>and maybe some other branch later on <jgart>I think that might be useful for getting started on setting up your own channel <apteryx>lfam: re gnupg, do you have a patch ready? feel free to push it directly to the version-1.4.0 branch <nckx>jgart: OK, interesting :) <jgart>nckx, A new user wanting to start a guix channel can do something like this: <lfam>apteryx: Testing build of dependent packages now <lfam>I'll push as soon as I'm satisfied there's no new breakage <jgart>and just like that, they have a channel template ready to go to be filled with packages <apteryx>lfam: i think emacs-pinentry is obsolete anyway <jgart>they'll just have to learn to sign their commits with gnupg <apteryx>I'm curious why the gnupg-next package didn't use the pinentry custom patch though? <lfam>apteryx: Yes, that's my understanding. But I was hoping to get some feedback or acknowledgment from Pierre, who packaged it, before pushing <jgart>lfam, I finally figured out that gnupg bug haha <lfam>apteryx: Oversight, I think <jgart>it wasn't that my key was expired <nckx>I still have pinentry-emacs installed, good to know it's obsolete. <nckx>Hardly. But I thought it still worked. <jgart>lfam, the date I had mentioned to you that time was not the expiration date but the creation date ;() <apteryx>last time I struggled with pinentry (4 years ago?) this was my conclusion reading left and right <apteryx>I haven't used it since, yet I'm using GnuPG with Emacs fine <lfam>I think we should drop it if it can't be used with current GnuPG <nckx>Thank you lfam. I'll make those changes and drop the old package. <nckx>(From my profile; not Guix.) <lfam>jgart: Remind me of which bug? :) <jgart>The issue was a gnupg2 compat mode I had to install on void linux since gnupg2 instead of 1.0 is apparently needed for signing <apteryx>I still keep it in my config for historical purposes <nckx>apteryx: But you still need allow-emacs-pinentry, rite? <lfam>The gnupg update is fairly high-impact. But berlin is building top-level dependents as fast as it can <jgart>lfam, the bug was just that I couldn't sign my commits and I was getting some gpg error every time I tried <lfam>I suspected the key had expired <lfam>So, the creation date was at fault? <jgart>lfam, nope it wasn't the creation date <jgart>the creation date had nothing to do with it <dissent>hey guix, is there an equivalent to `apt purge`? <jgart>void linux has this gnupg compat mode that fixed it <lfam>To clear "extra files" away dissent? <jgart>I'm not entirely sure why they have a compat mode <jgart>probably for some good reason <lfam>Yes, I'm sure they did it for a reason <lfam>One should always assume that <nckx>It helps (like with ‘Nix flakes’ above) to phrase questions in more practical terms than ‘what's Guix for apt florp bloo’. <lfam>No dissent, not as far as I know <apteryx>lfam: are you going to send patches for gnupg and the other gnome thing? <nckx>Not to be grumpy, I just find myself spending relatively much time looking up apt florp bloo equivalents I don't actually need. <nckx>dissent: Guix doesn't track configuration like apt does. <lfam>apteryx: I was just going to push the gnupg change to version-1.4.0, but I can send a patch first if you prefer. The gnome thing being the glibmm double-propagation bug? <nckx>That requires maintaining a list of observed configuration files for each package. <jgart>lfam, I also had the wrong thing in my gpg-agent.conf <apteryx>I'm going to smoke test the branch 'manually', then if all looks OK I'll have it crunched by cuirass <lfam>I'm building all the first-level dependents of gnupg apteryx, comparing to current master, and then I'll try upgrading my profile based on the update. I use gnupg for encryption and signing, so I can test it decently <roptat>what does that mean: "guix shell: error: integer expected from stream" is that a network issue? <jgart>I was pointing to a pinentry in the store with a dynamic hash instead of the one in .guix-profile/bin/ <nckx>apteryx: Do you have pinentry-program in your gpg-agent.conf? I have it set to current-system/…/pinentry-tty so it works from non-emacs. <jgart>not sure why i thought that was a good idea at the time <lfam>Ah jgart. Classic pitfall <nckx>Not sure if that could break Emacs'. <jgart>nckx, that's what I have currently <nckx>And pinentry works in Emacs? <apteryx>lfam, jgart there was a commit made by civodul supposed to make gnupg-agent work out of the box without extra config <apteryx>perhaps your experiences are dated (mine is) <nckx>These files are years old. <nckx>I think I'll comment out all pinentry stuff entirely and see what breaks, if anything. <jgart>I haven't tried with emacs. I think we're talking about two different topic conversations with a lot in common simultaneously <lfam>apteryx: Do you recall which commit? Was it the pinentry patch for gnupg? <apteryx>nckx: oh wait, I *do* still have allow-emacs-pinentry in my gpg-agent.conf <lfam>I just want to make sure I don't unnecessarily re-introduce that patch, apteryx <jgart>apteryx, do you happen to remember which commit that was? <lfam>By the way apteryx, do you know which commit it was? <apteryx>trying to find it, but not much luck thus far <lfam>So, "the pinentry patch" <lfam>I'll investigate to see if it's still necessary or not <lfam>It will be a few hours before I'm ready to push, but I do want to push today <iyefrat>this may be a dumb question, but how do i properly uninstall guix (on a foreign distro)? <iyefrat>i couldn't find this in the manual, are the instructions there somewhere? <lfam>I don't believe there are instructions <nckx>I don't know, but removing /gnu/store /var/guix /var/log/guix ~/.cache/guix ~/.config/guix should be all of it, unless I forget. <apteryx>found it: "apteryx breatheoutbreath: for what it's worth, it's supposed to work OOTB without specifying pinentry-program since commit c7af9d0b5ebaa1fdb08ff5d8a56004998bcd8103 (Mar 26 2020)." <lfam>I would recommend these things: 1) Stop the guix-daemon 2) unregister the guix-daemon from your service manager 3) delete /gnu/store 4) delete /var/guix and /var/log/guix 5) delete /etc/guix 6) delete ~/.guix-profile 7) delete ~/.config/guix <lfam>There may be some other caches remaining but they are just caches <apteryx>lfam: so that's what this gnupg-default-pinentry.patch is about <nckx>Right, /etc/guix isn't just Guix Systems 🤦 <lfam>apteryx: Right. That commit didn't work and we followed up in e5b44b06b3fb19c897fb3e430bd41941905e101f <iyefrat>sounds sensible, but doesn't the guix install script create some users to do the building? <attila_lendvai>the entire file operates with 'undefined, this is the single match of 'disabled <iyefrat>i gotta tell ya every time i need to deal with system users i'm worried that i will break something, i don't deal with this often enough to remember how it all works <unmatched-paren>but it doesn't really matter, since you can get another mini-shell like waybar <iyefrat>do you think having an official way to uninstall would be a good thing to bring up on the mainling list or something? i feel like that should be a thing <iyefrat>prob not super high on the priority list tho <lfam>Yeah, it's worth bringing up. It's likely that somebody will be interested in implementing it <nckx>Patches would be welcome, or maybe someone will volunteer after this or the next time someone asks, but method #1 is fool-proof 😉 <iyefrat>well, maybe that's something i can contribute then, once i figure out how to do the user things <lfam>It's like, I didn't think an installer script was worth it, but it turned out to be really popular. What do I know <unmatched-paren>actually, wf-dock and wf-panel do work, but only if you pass ASAN_OPTIONS=new_delete_type_mismatch=0 to them <lfam>If you are worried about dealing with the build users, you could just leave them there <unmatched-paren>wf-background doesn't work at all, but i guess you could try swaybg or something <lfam>They should have a home of /var/empty and a shell of `nologin`, so fairly harmless <apteryx>lfam: the problem with emacs-pinentry won't exist if the base gnupg package is bumped <apteryx>it's just to avoid clashes between two variants <iyefrat>also like, i tried to do `sudo -i guix pull` for the first time in forever and got some sort of exception, so my working hypothesis is that it's because the previous version is super old <lfam>Could be, if it's very old <lfam>I remember when we could update gnupg without causing so many rebuilds... things change <lfam>Hopefully we'll soon have the capability to do short-lived staging-esque branches <lfam>I guess we'll find out with the version-1.4.0 branch <iyefrat>oh also i have another question: if you download a stable guix binary and run `guix pull`, does it keep guix at 1.3 or get it up to date with the latest head <lfam>It updates `guix` itself <iyefrat>so why have the stable one? for people to install and never update? <lfam>It's just a way to provide installers that are not like 5 years old <lfam>We don't offer a "stable" branch or anything like that <lfam>Also it's good publicitly to make a release <iyefrat>but there are two versions, the "stable" install and the "latest" one, so why have both if the stable updates anyway <lfam>That word doesn't appear on the download page :) <lfam>The other thing about a versioned installer: we've tested it <iyefrat>it does in the link in the top bar :) <lfam>The latest installer is basically untested <lfam>We'll probably change that, based on your feedback <lfam>"Stable" means something to Linux users and we don't offer that thing <iyefrat>yeah snapshot would probably be better <lfam>I'd say the big difference in practice is that we test the release installer <lfam>It's very hard to get it right and the 'latest' installer... we're lucky if it works <lfam>Like we have a test suite, but the job of the installer is so complex that it's hard to automate all the testing that is necessary <iyefrat>i would write that on the website somewhere, because that means that it's still a good idea to use the release installer and then upgrade even if you want to live on the edge <iyefrat>well, everyone does, but it's unclear from the website <lfam>Right, that's the workflow that is supported <lfam>I'm not sure if "snapshot" communicates what we want. <lfam>We could change latest to "latest (automatic untested build)" or something <lfam>This stuff is way harder than maintaining packages :) <singpolyma>If latest is unlikely to work, why put it out at all? <lfam>I like that unmatched-paren <lfam>It's idiomatic and Linux users will understand it <singpolyma>I think having release at all for Guix is confusing, but I understand the reasons for it <lfam>How else would it be installed singpolyma? <singpolyma>lfam: installer same as now, but no version or related terminology, just "run this and it installs, yo, then always run pull after" <iyefrat>well, lfam is right that versions are good for morale <iyefrat>also from the perspective of potential users that are unfamilliar with guix <singpolyma>iyefrat: yes, I know. It's confusing to outsiders but I agree with the internal morale thing <unmatched-paren>we could just update the installer whenever we feel like enough time has passed, this seems like something that wouldn't really benefit from versioning formalities <lfam>singpolyma: I guess there are two approaches. We do "waterfall" with the release, and then you get onto the rolling release afterwards. If our QA process improves we could maybe be able to keep an installer working constantly <lfam>As it stands now, installing Guix System from a random commit is going to be more painful than we prefer <lfam>Installing is way harder than updating the installed system <lfam>It touches the one thing that can't be rolled back: the bootloader <lfam>So it's crucial to get it right <unmatched-paren>well, you can always chroot in a live cd and then sudo guix system reconfigure there, right? <singpolyma>Yes, for sure. Maybe it could say "installer version" or something to not imply you care about the guix version number. But I'm just making things up here <lfam>Maybe we are too stuck in our ways to try the non-waterfall method. Personally, I think our CI and QA processes need to keep improving before we can commit to offering just a nightly installer <lfam>unmatched-paren: Sure, but that's not good enough <lfam>That's a last ditch rescue effort <lfam>We want to offer something that works reliably <lfam>And we already struggle to meet that goal <lfam>And remember, the project is young and small. We need publicity <singpolyma>Yeah, it's just hard to communicate that "guix release" or "guix version number" is borderline meaningless to an existing user. So you get people (like me) looking at the manual for "the release version" which no one is running, stuff like that <singpolyma>But I'm not saying I have a great idea how to be better and keep the benefits <lfam>singpolyma: Yeah it's tough. The truth is that the original core of Guix developers expected people to use the info manual that is kept up to date locally. The web manual was not expected to be so popular <lfam>Just a difference of experience and preference <iyefrat>with regards to the manual you can just host the latest version if you want <lfam>Guix was created by people who live and breathe GNU, which means info manuals <lfam>Yeah I know. Just trying to explain the context of how we got here <iyefrat>or you can have the "stable" version and link it to the actual one, with a notice at the top about the thing <lfam>I type 'guix devel' into the browser and choose between the mailing list or the latest manual :) <rekado_>apteryx: I haven’t tested the patch in 40039; I’d like to reproduce the problem first and then look at the patch again. <iyefrat>or without the notice, if you explain the guix install process early in the manual more people will be aware of the fact that version numbers are just milestones <lfam>The website does link to both versions of the manual <lfam>Milestone is a good word for it <podiki[m]>dissent: that was supposed to be fixed....but i haven't tried, let me get the bugnumber <iyefrat>yes but given the fact that no one is actually using guix 1.3.0, having the manual there is more confusing than anything <iyefrat>i would suggest having only the latest manual, and in the install section explain the thing about guix constantly running on head <podiki[m]>we've discussed the confusion over the manual here before, would be good to get sorted. a manual snapshot matching the installer version is useful though (as that will be what's in the iso and matches the system at that time) <lfam>Maybe the two manuals could be named 'current' and 'version-1.3.0' or something? <lfam>Instead of 'stable' and 'latest'? <zimoun>iyefrat: maybe it is confusing, but the webpage says: «Download latest GNU Guix System images built by CI» and «These images are development snapshots». So I miss what could be improved? <podiki[m]>but agree we need the "devel" manual on the website to be more obviously what users want <nckx>The official ‘stable’ installer is used and still at 1.3.0, so it's not unused, but I do actually agree with you, iyefrat. <nckx>Is a stable installer even the safe option it's assumed to be? <iyefrat>lfam: yeah i think that would be better <lfam>Considering the traack record nckx... <lfam>It's very hard to get it right <podiki[m]>at least me, and I see others, had better luck with the current "nightly" or whatever over 1.3.0 (paritioning issues) <singpolyma>nckx: yes, people install stable, but then the first thing they do is run guix pull... <nckx>lfam: <Considering the track record> The fact that I can't tell which direction you lean says enough. <lfam>The installers are not as reliable as we'd like <lfam>Too often, we release with problematic bugs <lfam>It's just really hard to exercise everything <singpolyma>Need to package guix for more distros. apt install guix is pretty great <nckx>singpolyma: It's not actually recommended to run it before installing. (Another statement of fact that doesn't mean I agree.) <lfam>Maybe if we had an entire day of the Guix Days dedicated to testing the installer, with 40 people all trying it... <zimoun>lfam: we really did only once. For v1.0.0 :-D <podiki[m]>dissent: darn. could you reopen or maybe file a new bug? i haven't had a chance to try it yet either <zimoun>lfam, nckx: IIUC, stable -> last release and latest -> devel. Right? <nckx>If I used ‘stable’ without quotes it's not what I meant. <nckx>As lfam rightly notes, we don't do nearly enough QA to hand out such a label. <lfam>I think 'stable' is confusing because it means something else for old-school distros <lfam>We don't offer a "stable" branch <zimoun>It sounds a reasonable change. :-) <podiki[m]>then maybe for the manual issue we can just have one version linked (the "devel" one) and in the installation section it could have a note to refer to the manual snapshot that corresponds to the installer release <nckx>It's just a snapshot that presumably a few people tested. <nckx>But not even that ‘well’. <nckx>Which is not to blame them! That's hard. <lfam>And we try harder to increase substitute coverage <lfam>And make some decisions about which architectures to support <zimoun>It is written «These images are development snapshots, you might prefer to use stable images» but indeed “stable” is confusing since it is “latest released” <podiki[m]>maybe just "release version"? so it doesn't imply much? <nckx>Veering off topic a bit, I don't see the need for a Web-hosted arbitrary snapshot manual anyway. Just host ‘devel’ (master), and note that ‘the manual installed with your version of Guix should always apply to that version, if different’ or something. <podiki[m]>nckx: I basically agree; but could be handy for someone to have a web version that matches what they are seeing in the installer, no? <singpolyma>podiki[m]: why would they see anything that needs a manual in the installer? <podiki[m]>if you go more manual or need to tweak the config <rekado_>podiki[m]: the installer includes the manual <nckx>People differ, so I can only assume there must be a human out there that for reasons unfathomable to me wants to connect to a Web server in Berlin to read the documentation they have waiting on tty2. <podiki[m]>but the web version can be handy to have, esp if you have another computer/phone <nckx>Maybe it involves telephones. I'm still not convinced but who knows. Does it justify hosting it? Dunno. <podiki[m]>I think it is a valid option, especially these days with multiple screens <iyefrat>i think a lot of people aren't comfortable with using info to read stuff <iyefrat>i am somewhat included there i only really started using it recently <podiki[m]>also, you may want to read before you install (! heaven forbid reading the instructions first!) <kwjc1>I, as a normal user, didn't even know that 'info guix' was a think until I saw it mentioned here <zimoun>Aside confusing “stable“, I do not see the issue to have 2 manuals; one for the last release, one for the last commit. <nckx>We're all normal users here. <rekado_>so… what if we had a browser in the installer image and it looked up the local HTML variant of the manual? <podiki[m]>same. i've rarely used 'info' before (trying it more now, does seem nice) <dissent>kwjc1: try using info from inside emacs if you're an emacs user. <zimoun>rekado_: which browser? Because the image could be huge, no? <podiki[m]>having a full graphical environment for the installer could be nice, though I'm sure introduces all sorts of complexity <nckx>It would have to have a Firefox-style UI or the same arguments apply though. <iyefrat>zimoun: the only issue is that people that are using guix but are unclear about the fact that the installer version is just the initial guix version, and they may end up using the wrong web manual <rekado_>I’ve rarely used info because Arch removed all info manuals… When I learned that GNU software came with real manuals and not just short man pages I was delighted. <Gooberpatrol_66>are the info pages and the HTML pages identical? it's seemed to me that the HTML version contained more information. <podiki[m]>having options is nice, but needs to be clear what the optionos mean <nckx>Sorry, that's deprecating other distros and not on. I take it back. Arch is different, that is known. <iyefrat>rekado_: i don't think this is true, `info grep` worked fine <nckx>Gooberpatrol_66: They don't. <singpolyma>rekado_: I've had the opposite, with Debian the manpages are usually so complete I never thought to look elsewhere <rekado_>Gooberpatrol_66: the HTML version does not contain any more information. <nckx>Gooberpatrol_66: That would be a strange decision. <rekado_>even if you want to say things like ‘but it has images!’ — yes, the info manual also has images. <lfam>My reasons are truly unfathomable nckx :) <zimoun>iyefrat, that’s because the current “label” (stable/latest) is confusing. But we can replace by release/current or release/master or release/devel. <rekado_>iyefrat: I last used Arch in … 2010 maybe. <lfam>Worse nckx. I'm a `man` and `vim` user <nckx>Can you read man pages in vim? <iyefrat>zimoun: i think release/current is the clearest <zimoun>singpolyma, installer/current is confusing because you can install using the devel snapshot. :-) <singpolyma>Or there is a key to open manpage of current word under cursor <singpolyma>zimoun: well, but you can't really that's the while discussion right? <unmatched-paren>there isn't (afaik) but it wouldn't be too hard to add one using viml or lua <singpolyma>nckx: because the nightly installers are usually broken, says lfam <nckx>You're currently nudged towards using the 1.3.0 one but using ‘latest’ should and usually should work. <zimoun>singpolyma, I do not understand what you mean with «well, but you can't really that's the while discussion» <nckx>That is not my experience, at all, from suggesting it to people having trouble with 1.3.0. <nckx>Either the bug remains or the installation suddenly succeeds. <singpolyma>nckx: ah, well, I have no experience here just what I was told up-thread <nckx>That's not data, of course, but I have some very pretty anecdotes. <lfam>Not exactly "usually broken". But untested <jpoiret>from what I've personally seen, the latest installer works better than the 1.3 <lfam>nckx: I didn't know you could read man pages in Vim <nckx>s/usually should/usually does/ <jpoiret>but, not right now, since we're missing some patches in local.mk <nckx>lfam: Are you disappointed now? <lfam>I might switch to l3afpad <singpolyma>Even nvi has the key to open man I think, but it execs man with an outside pager iirc <nckx>Oh, this is irrelevant but reminds me: man xdg-settings broken for others? <florhizome[m]>In further news, wayfire 0.7.3 is approaching, (wlroots 0.15 got released) so we can actually send it upstream then. :D <sneek>florhizome[m], you have 1 message! <nckx>florhizome[m]: Great news. <lfam>This is great raghavgururajan <lfam>I'm going to put it in my profile <singpolyma>raghavgururajan: because you asked me the other day. I have a working cheogram package def for Guix on my workstation now <unmatched-paren>what i like about wayfire: fast, eye candy, extensible; what i don't like: wf-shell doesn't work :P <florhizome[m]>I could put wayfire on the list tomorrow btw, i would like to avoid the wrapper script by setting search paths <nckx><wf-shell> What a confusingly named status panel. <unmatched-paren>gnome is still prettier and easier to use, but wayfire is a lot faster <florhizome[m]>If you want gnome lightweight, I have gala now too (pantheon) <jackhill>unmatched-paren: neat! Any plans for merging that into Guix? <unmatched-paren>nckx: it's _going_ to be a full shell for wayfire, but right now it contains only a barely functional dock and panel and a non-functional background thingy <unmatched-paren>jackhill: it uses an unreleased version of wlroots, which is problem <jackhill>unmatched-paren: you may also want to be more careful about removing folks' copyright lines when lifting code from guix *raghavgururajan hasn't got a chance to get to the dependencies of cheogram thread <nckx>xfe is a fascinating set (suite even) of utilities. I'd never heard of these. Feels like discovering some forgotten… something. I don't know what to think. <singpolyma>raghavgururajan: well, once I get descriptions written for the few more I had to do I'll send that along toi <jackhill>unmatched-paren: fingers crossed that this wlroots doesn't have to go through core-updates :) <nckx>unmatched-paren: Ah, thanks for the info. <nckx>If they stop tracking Meson head like a crack addict it might not need to. <unmatched-paren>wf-shell was the only part of wayfire i was disappointed by, really; even when i did get it to sort of work, the panel and dock looked kind of ugly <singpolyma>Description writing is the hardest part. No automated tooling can help me 😉 <unmatched-paren>i'll have a look at carbon-shell... maybe we can package that, it's just a wayfire plugin i think <florhizome[m]>unmatched_paren I may correct: wf shell doesn’t have much priority since devs built wayfire to be used by DEs. It’s more of a proof of work. There are some interesting MRs though that would probably make it much better. <florhizome[m]>they need some protocols to make interaction about workspaces and client/server transactions easier to get to stable release (or 0.8, first), wf shell will probably get attention when wayfire is production ready for DEs <singpolyma> Oh good, because nothing else is called carbon and graphite.. <apteryx>rekado_: odd, test-name: wrap-script, with encoding declaration fails for me with the patch, but with no discernable mismtach in the expected vs actual outputs <nckx>This shows my ignorance of Wayland coming from X11: do you need a compositor-specific panel like wf-shell for each one, or could I just keep my tricked-out swaybar? <florhizome[m]>Other programs would be nwg shell and wapanel that can be used for graphical shell. anything wlr compliant. <florhizome[m]>nckx: Waybar will probably work better but in each case you will have to see what uses sways Ipc and what uses wlr protos <florhizome[m]>I’m up for a community channel for funky stuff like Frankenstein DEs *lfam feels dissatisfied with their Core i5-6300U <lfam>I wonder if an equivalent laptop (x260) with i7 is worth it <nckx>wc -l .config/i3status/* → 110 .config/i3status/config | 96 .config/i3status/custom.sh | 206 total <lfam>Or is the thermal management not good enough to matter <nckx>I really don't want to rewrite that. <unmatched-paren>(unmatched-paren searches nwg-shell and is immediately interested by what seems to be a shell for wlroots that can be tweaked to look like gnome) <lfam>Could be. I can open it up myself and check the fan. That's a good idea <lfam>I can try out the new screwdriver set I just bought :) <ngz>About texlive packaging: how do you know what file goes where? At the moment I look at README in the source or the Makefile, but sometimes information is missing. <unmatched-paren>florhizome[m]: i see you are using a gui matrix client, judging by the confusion between I and l :) <lfam>My fan is definitely running fast <florhizome[m]>I am using element from my mobile devices most of the time, I only log into ement.el to paste stuff <lfam>I don't want to manually manage thermal stuff or power <florhizome[m]>reapplying thermal paste and cleaning the fan doesn’t hurt anyways. <lfam>Yeah I'll try cleaning it <lfam>No I use whatever it came with <florhizome[m]>Intel thinkpad cpus seem to have a long history of overheating <lfam>That's what I was getting at about the i7. Actually clearing out all the waste heat from a laptop is not that easy <lfam>The i7 can run at 25 watts <lfam>That's a lot of power in a tiny space <lfam>I guess it's the same as my i5 <lfam>It's also a "launch date 2015" + Spectre problem <lfam>Could be improved, maybe not by much without using Apple <lfam>I tried benchmarking the Spectre mitigations and it wasn't measureable on some older Intel chips <unmatched-paren>jackhill: i've added the copyright notices from vim.scm to my nvim.scm now :) <nckx>lfam: <benchmarking the Spectre mitigations> Cool that you actually bothered. <nckx>My CPU runs at 45W by the way; now this sounds crazy. <lfam>I think the bottleneck was probably somewhere else... way slower than what Spectre mitigations could affect <florhizome[m]>unmatched_paren yes :/ I avoided it so far. We’d need to build gotkmm. <florhizome[m]>I have built swaync, and nwg-launchers which is the predecessor to nwg shell, but only a logout bar menu, a full screen launcher and a gtk dmenu in gtk jm <jackhill>unmatched-paren: thanks! And thanks for pusing the neovim and compositor work forward <nckx>Retrofit, but runs fine, really. It can max out the fan but that's normal. <nckx>Anyway, IME, an i7 it was meant to contain + new paste shouldn't be throttled. <lfam>I can get an i7 x260 on ebay for $200 <lfam>Not bad considering that I'd sell this one for close to that <nckx>What kind of workload, roughly, did you benchmark? <lfam>Looks like me job is going away for a while again so I need a project to keep me busy <lfam>Compilation of some packages nckx <florhizome[m]>Actually thermald contained my temp to95 degree celsius if you need an ad how solution <nckx>At what cost to performance florhizome[m]? <nckx>I just mean frequency, nothing fancy :) <florhizome[m]>I’m pretty sure tlp and thermald overlap in functionality, too. <unmatched-paren>i'm guessing since it uses a modern language it will have five gazillion dependencies <unmatched-paren>whoa that was weird, if you leave wayfire running it goes into a fancy spinning screensaver and it suddenly started spinning really fast *nckx hah! had noticed a (not-so-)sneaky running tail -f nginx.log during the Great Uncertainty, and wondered… <florhizome[m]>The nice thing about wayfire is definitely having a very customizable compositor with animations etc that just idles at 39 degree <unmatched-paren>and of course is great for composition within a greater desktop environment <unmatched-paren>i do want to make guile bindings to wayland and xorg themselves (so i can do gfx stuff), i'm not sure how hard that would be <nckx>lfam: Thanks for pushing the CB patches by the way! <unmatched-paren>florhizome[m]: pah! how dare you suggest such impurities as fennel, with its vile [list syntax]! TRUE lisps use '(for lists)! <lfam>nckx: what are the CB patches? <nckx>Coreboot kernelly stuffs. <unmatched-paren>it even has {hashmap syntax}, which is enough to make even the least pure lisper keel over! <apteryx>we should automate the move-static-lib thing <lfam>It might be painful but we should start removing qtwebkit <unmatched-paren>Super-scroll and you're now able to read small text, it's a really nice touch <lfam>Already the package we offer says this on its release page: "Please use it carefully and avoid visiting untrusted websites and using it for transmission of sensitive data." <lfam>And development is not progressing <unmatched-paren>florhizome[m]: i vaguely remember you also sending over a wayfire-xyz file... am i remembering correctly? <rekado_>there are quite a few packages that have qtwebkit among their inputs. <lfam>Yes, it's true rekado_. This is why I say that it might be painful <rekado_>can we build them all without qtwebkit? <rekado_>we already have python-pyqt-without-qtwebkit <lfam>It will be a bit like removing Qt 4. We did lose some packages <lfam>I think I can start a tracking bug today. I find that it's motivating to make a patch series that just removes everything <florhizome[m]>That’s swayfire, wf lua, an easy stroke (mouse gestures) and an advanced wallpaper plugin. And a gsettings backend that you need for the latter <lfam>Then people can send followups to save their favorite packages <unmatched-paren>since you had to resend it because legal blahblah, was there a licensified version of wayfire-xyz? <florhizome[m]>you only sent me the header anyways so iThought that’s for all <nckx>lfam: SGTM. I see things like hplip ‘depend’ on it, presumably through PyQt. <nckx>I'm guessing that's bogus. <lfam>nckx: Yeah, maybe the pyqt variant would work *nckx momentarily forgot about guix graph; it's pyqt. <lfam>Can I recover a deleted worktree via reflog <florhizome[m]>But the whole catch about sr.ht is that that’s possible for nonmembers, no? <Kolev>unmatched-paren: I went with Gitea because Source Hut has an ugly hacker look. <singpolyma>Kolev: I think people prefer to say "brutalist" ;) <Kolev>If I want that, I'll use cgit. <Kolev>Go to ess ar dot aitch tee slash cee ess aitch <Kolev>Go to code berg dot org slash cee ess aitch <singpolyma>florhizome[m]: yes, I use the guix CI as well as the Debian one <unmatched-paren>btw, florhizome[m], i just noticed that you wrapped wayfire in a wayfire-run.sh script <Kolev>unmatched-paren: i still think codeberg is easier to pronounce <Kolev>How is the elogind bug going? <unmatched-paren>also, why does the wayfire package use both elogind and seatd? isn't only one necessary? <jpoiret>unmatched-paren: only one should be necessary <jpoiret>but it depends on what it aims for, (e)logind has more apis than just seat management <nckx>It's the current default. <Kolev>Which is not working right now <apteryx>move-doc doesn't seem as automation-friendly *raghavgururajan would say that sourcehut is the best thing ever happened with regards to web-applications <nckx>I thought someone managed to reproduce the elogind race with a suitably leashed QEMU? <apteryx>mroh did once, I think... can't seem to be reproducible yet there <apteryx>jpoiret: yes, that's what we tried (bps, iops) <nckx>(CPU too, of course, but I don't think that was the issue here.) <unmatched-paren>florhizome[m]: can you send over wayfire-xyz on paste.debian? i feel that would probably be easier than signing up for codeberg <raghavgururajan>Wayfire seems interesting. It would have nicer if used Lisp, I think. The goal of hackability would have been more awesome. <mroh>It's frustrating, we couldn't reproduce it with several qemu images with several throttling options, but on the real (HDD) box's it happens every try. Rebooting work/desktop machines all day is no fun ;( <jackhill>yeah, if only rust packaging weren't so aweful <florhizome[m]><unmatched-paren> "florhizome: can you send over..." <- I just signed up <florhizome[m]>it would be pretty nice to have a compositor integrate with guix :) <unmatched-paren>it's a shame that 'fast' and 'functional/declarative/pure' seem to be mutually exclusive with languages <unmatched-paren>apparently in a bygone age ocaml used to be as fast as c, but no longer <dthompson>I've thought about doing some wayland stuff with guile but there's a pretty big barrier to entry to learn it all and write guile code that can speak the protocol <unmatched-paren>you'd need to write bindings to libwayland i'd think, since there's no bindings currently available that i know of <unmatched-paren>all the guile-charged wms that i've seen while searching around are written in c, but use libguile <florhizome[m]>The problem of rust on wayland seems to be that wlroots is implemented in c++ and there just seems to be so much unsafe stuff for rust that it’s having a hard time <dthompson>I don't know if linking against a C library is necessary <singpolyma>unmatched-paren: Haskell can be pretty dang fast <jackhill>do compositors need to be inherently unsafe though? <Kolev>I wish Hikari were as mature as Sway. I dislike tilers. <singpolyma>It can be "as fast as C" if you write it really stupid. But also perfectly fine when written reasonably. Faster than most popular stuff <florhizome[m]>if you want to do all the work again then I guess we’ll see each other in a few years <unmatched-paren>hey look i managed to make haskell as fast as c by ffi'ing malloc() and free()! <singpolyma>unmatched-paren: well, you don't have to get quite *that* stupid <jackhill>unmatched-paren: oh, what are the other rust compositors? <florhizome[m]>If wlroots would have bigger problems I think you would know by now. But what do I know. <singpolyma>Also "as fast as C" is funny. I can write some pretty slow C <jackhill>I guess I should be better about reporting sway/wlroots bugs, but back before core-updates and we had the ancient versions, was hoping that they were just fixed :) <jpoiret>why are we having a debate about wayland compositors again? didn't we agree just yesterday that wayfire was The Next Best Thing™ <unmatched-paren>we're not debating, we're just discussing the fact that some rust wayland compositors exist and also that wayfire would be way better if it was configured with lisp <unmatched-paren>although it would be entirely possible to configure wayfire with lisp if someone made bindings <Kolev>raghavgururajan: guile stumpwm <unmatched-paren>oh, florhizome[m], if you submit a pr, you'll need to go through the painful process of gpg verification <tex_milan>Hello, how to install neovim with python-pynvim? I just installed those two, but in neovim it tells me it python can't do import neovim. When I run python3 it also can't import neovim. Where the python-pynvim was installed to? <unmatched-paren>i only found it painful because i had to figure out how to create an empty branch <unmatched-paren>florhizome[m]: you'll need to create a keypair in gpg, if you don't have one, and then dump the ascii-armoured public key into florhizome.key in the keyring branch <jgart>raghavgururajan, have you tried mahogany <tex_milan>with guix shell python3 python-pynvim it works as expected <unmatched-paren>`keyring` is already there on my channel, you'll just need to clone, checkout and dump the key <tex_milan>never-mind, just log off and log in. that helped. <jgart>raghavgururajan, let's make swm great again... jk. I don't think I have the time for that <florhizome[m]>I posted sth in the other channel yesterday, the issue prevails <lfam>Does anybody have something I can run that will give me the package names of every package using the go-build-system? <lfam>It's useful but there end-user applications aren't named with the 'go-' prefix <lfam>There is a way to do it in Scheme <slimjim>hi Guix, I'm trying to define a gdb-multi package that inherits from the main gdb package, but adds some configure flags. I'm experimenting with different flags - but after installing the package once (via a gdb.scm in a path I set with GUIX_EXTENSIONS_PATH and then guix package -i gdb-multi), I can't get the package to rebuild after changing the <slimjim>configure flags in my package definition - it just says 'nothing to do' because I've already installed the 'gdb-multi' package. <unmatched-paren>did you install it, or just build it? if the former, try 'guix remove gdb-multi' <slimjim>I tried "guix package -r gdb-multi" which removed it, but it didn't flush it from the store, so a subsequent "guix package -i" just re-used the same store path without rebuilding using the new flags <nckx>Hm. If guix isn't rebuilding it it's just not seeing your gdb-multi. Neither uninstalling nor gc'ing will change that. <nckx>There is no ‘flush from the store’, builds are input addressed. Guix won't install new binaries to /gnu/store/old-hash-gdb-multi/. <jpoiret>shouldn't it be GUIX_PACKAGE_PATH instead of GUIX_EXTENSIONS_PATH? <florhizome[m]>damnit I wanted to do some light guix mail things to be able to do it tmrw <nckx><just re-used the same store path> not for the reason you think. <nckx>jpoiret: That does sound more familiar! <slimjim>sorry yes I had two things in my mind, GUIX_PACKAGE_PATH is what I'm using <lfam>slimjim: How about `guix show $yourpackage` <slimjim>well it's seeing the definition, because gdb-multi isn't a name defined in core guix, and I can "package -r" and "package -i" to uninstall and reinstall - but it doesn't look like changing the configure flags is triggering a rebuild <nckx>Then you're not changing the configure flags as far as Guix can tell. <jpoiret>how are you changing the configure flags? can you post your package definition? <nckx>Does ‘guix edit gdb-multi’ show your new flags? *nckx doesn't know if that works with G_P_P though. <slimjim>(define-public gdb-multi (package/inherit gdb (name "gdb-multi") (arguments (substitute-keyword-arguments (package-arguments gdb) ((#:configure-flags flags) (append flags "--enable-targets=all")))))) <slimjim>and when I change the "--enable-targets=all" to something else, it's not rebuilding <jpoiret>(append flags "--enable-targets=all") shouldn't work, the second argument isn't a list <slimjim>(append flags '("--enable-targets=all")) ? <jpoiret>yes. Although this isn't the root of the issue, as you would've gotten an error <nckx>(#:configure-flags flags) `(append ,flags (list "--en…"))) ; I think. <jackhill>Can someone test to see if you're able to reproduce this issue: https://issues.guix.gnu.org/52375 Vivien couldn't, but I just tried again and it persists for me (across multiple computers!), so I find it really odd. <nckx>Otherwise you're throwing away the old flags. <jpoiret>jackhill: I thought I had replied to that thread. My guess is that the gstreamer shared lib cannot be loaded. <nckx>florhizome[m]: You can't really ‘pull’ all branches in that sense, but you can git fetch --all. <lfam>jackhill: Both of your URLs load fine for me <vivien>jackill, the most probable reason is I have other things in my profile that makes it work. If I run with --pure, I can still visit the pages, but clicking the "play" button makes the page fail <jpoiret>jackhill: Can you set LD_DEBUG=all and reproduce? <jackhill>what's wierd is that I was just able to play an embeded yt video, so clearly some AV stuff is working… <slimjim>nckx: quasiquote seems to have gotten me farther, now `guix package -i gdb-multi` says The following package will be upgraded: gdb-multi (dependencies or package changed): gdb-multi ... but then says "nothing to be done" <lfam>jackhill: Is there a browser cache that you can delete? <florhizome[m]>how does the packaging meetup proceed, does it have a pad or do we communicate live via mail :D <nckx>slimjim: OK, now I admit to be a bit stumped at first glance ☺ <lfam>slimjim: My advice in general is to avoid using `guix package` while testing builds. I recommend using `guix shell $package` to avoid getting about the state of one's profile <lfam>I would also look at the derivation (`guix build $package -d`) to be sure it includes the configure flags that you expect <nckx>slimjim: Do ‘realpath $(which gdb-multi [or whatever unique binary it provides])’ and ‘guix build gdb-multi’ print the same store path? <jackhill>lfam: still getting it after rm .rf ~/.cache/epiphany <nckx>lfam: I think they'd be in the -builder, but neat idea. <slimjim>can i delete that specific package out of the store to try again? I am mistrustful of `guix gc` because it often removes a lot more than I want (e.g. I have to download a lot more stuff again the next time I run `guix pack`) <nckx>This is not how guix works. <lfam>Right, look in the *-builder that is named in the derivation <nckx>The store is not a mostlyworks cachalike. <lfam>And I agree with nckx, too. Using of `guix gc` here is a mistake <lfam>But, you can delete specific files with `guix gc -D /path` <nckx>I'll put it differently: you'd have found the most foundational bug in Guix in… ever? Not to dash your hopes of nabbing our impressive bounty of, eh, mad props, but it's extremely unlikely. <slimjim>nckx: yes, realpath... and `guix build` both show the same path <nckx>OK, so somehow you already have the gdb-multi that Guix ‘sees’, installed. <lfam>slimjim: Try adding some bogus value to your custom configure-flags. Like, "slimjim=awesome" <lfam>Then check the derivation of your package with `guix build $package -d` <lfam>Look in the *-builder file <nckx>Or --help, that's nice & clear when/if it fails. <lfam>If it includes that value, then something is fishy <lfam>If it doesn't, I'd say that your configure flags are not being used <slimjim>after changing the flags, guix build still reports the same store path <lfam>So, I think you are holding it wrong <florhizome[m]><nckx> "florhizome: You can't really ‘..." <- hm that did nothing <apteryx>so the new G-Exp style has only affected (assoc-ref outputs ...) and %outputs, correct? <apteryx>(assoc-ref inputs/native-inputs ...) are still valid, correct? <lfam>Sorry to rehash this, but did you share your package definition with us yet slimjim? The entire thing? <nckx>florhizome[m]: I think it did. It just has no ‘visible’ effect. <nckx>In my simple understanding of git, ‘git pull’ is equivalent to ‘git fetch origin/master && git rebase origin/master’, roughly. <unmatched-paren>florhizome[m]: wdym 'pull all branches', anyway? did 'git clone' and 'git pull' not get all the branches? <nckx>You did the first part, which is ‘all’able, but I don't think the second part is. <slimjim>lfam: yes, but I corrected it with qusiquote per ncks, here's the updated definition: <slimjim>(define-public gdb-multi (package/inherit gdb (name "gdb-multi") (arguments (substitute-keyword-arguments (package-arguments gdb) ((#:configure-flags flags) `(append ,flags '("--enable-targets=all" "--TEST" "--foo"))))))) <slimjim>adding --TEST and --foo didn't trigger any rebuilds <nckx>florhizome[m]: You still need to check it out. <lfam>Then, you are using (substitute-keyword-arguments) incorrectly <lfam>I will take a look and try to help <nckx>florhizome[m]: By the way, I was full of poop, there *is* an --all argument to ‘pull’, it just does the equivalent of ‘git fetch --all && git rebase origin/master’, it still won't check out ‘all’ branches. I don't think git works that way. I use a worktree for the keyring to avoid the multiple checkout dance. <nckx>Because checking out different branches each time screws up Guile .go caching. <nckx>Right, I meant the rebuild cost. <tschilptschilp23>Hi! Is there a way to run 'guix graph' on a package-definition file? Or do you have hints for a packaging-noob how to check for circular stuff? <lfam>slimjim: Also, you shouldn't use package/inherit here. Instead, you should use (inherit gdb) <nckx>slimjim: I don't use G_P_P myself so can't help debug why, but it's clear that at least ‘guix install’ isn't picking your (syntactically invalid) package. I don't understand what it *is* loading. <lfam>package/inherit is intended for a special case, which relates to grafting <lfam>slimjim: The crucial difference between what you shared is the empty list in the #:configure-flags part <lfam>Don't ask me why it matters, I copied it from the guix-daemon package <lfam>And I confirm that it doesn't work without it <Kolev>I need to bookmark the page on the elogind bug... <nckx>lfam is an honourary Schemer by now. <lfam>My grep skills are legendary <nckx>The awards ceremony just didn't happen this year. <jackhill>jpoiret: I uploaded the full LD_DEBUG output to the ticket. Unfortunatley, I couldn't spot the relivant part of the log, so I uploaded the whole thing 😓 <lfam>And I confirmed the effectiveness of the change in the way that I was suggesting: By reading the *-builder file that is named in the derivation <slimjim>lfam: that empty list for me is triggering an error <lfam>Did you copy my code exactly? <lfam>I don't know what to tell you <slimjim>and I get "unknown location: unexpected syntax in form () " <lfam>And like I said, I confirmed that --foo was passed to the daemon via the *-builder file <lfam>If you edited your package rather than deleting it and copying mine, I'd try that <lfam>Or, maybe we are using different versions of Guix that handle this stuff differently <lfam>I'm working on commit 94836b215630ad0f4a7c06b8e4284d923ac1197f <jpoiret>jackhill: did you just send the mail? I haven't received it yet. <lfam>Oh also, slimjim, my file imports these modules: (guix packages) (guix utils) (gnu packages gdb) <lfam>Maybe the error indicates a missing import <slimjim>lfam: is there potentially a module I need to include? The build derivation error starts with ice-9/psyntax.scm:2794:12: In procedure syntax-violation: Syntax error: unknown location: unexpected syntax in form () <lfam>You'd need to adjust the module path, or create a similar directory structure and adjust the value of $GUIX_PACKAGE_PATH <slimjim>hmm I'm on guix commit e874c730eaa369e42cff3b2c2e3599d33a7aceff, I updated fairly recently after core-updates-frozen was merged in <lfam>I doubt something changed, but to be sure I will try from that commit <slimjim>lfam your exact file also failed for me - but I changed the module definition to match my file layout, so it starts with (define-module (my-extensions gdb) ... <lfam>slimjim: I reproduce the crash from your commit <jackhill>I'm sure the important part is smaller, but didn't know how to identify that part 😀 <slimjim>lfam: the '() isn't used in e.g. /gnu/packages/version-control.scm when defining git-minimal <jpoiret>jackhill: could you retry with only LD_DEBUG=files,search instead if that's not too annoying? <jpoiret>that might have been a bit overkill previously <lfam>Okay slimjim. I copied an example from a package that is doing the exact same thing as you (appending flags). <jackhill>jpoiret: will do. haha, yeah, clearly. It also made it run really slowly <florhizome[m]>I really seemed to have sth else in my Clipboard that just produced confusion <jackhill>jpoiret: warning: debug option `search' unknown; try LD_DEBUG=help <lfam>Anyways slimjim, you could try it from my commit, to assist debugging <jpoiret>it's high time for me to sleep it seems <lfam>It fails on both commits when using the time machine <lfam>Ah, I see my mistake. I never actually built gdb-multi. Just checked the derivation for your flags <lfam>However, this syntax does work for guix-daemon, slimjim. So what's the difference? <slimjim>hmm when I did a guix pull I didn't so a `sudo -e guix pull` to upgrade the build daemon - maybe that's part of it? <lfam>However, I notice that gdb doesn't actually have any #:configure-flags. So, we cannot append to them? <lfam>I suspect that's the root of the problem <slimjim>So using the original def I pasted in here, when args where just '--enable-targets=all', it did build, but then looking at the build log, there was a "starting phase configure" <slimjim>and then configure flags: ("CONFIG_SHELL=/gnu/store/5pdmm36mvq8cb994z90blyk02jz7zvfv-bash-5.1.8/bin/bash" "SHELL=/gnu/store/5pdmm36mvq8cb994z90blyk02jz7zvfv-bash-5.1.8/bin/bash" "--prefix=/gnu/store/a5m2rsv3yfaa9w87n4p96xkpzz3rymcb-gdb-multi-11.1" "--enable-fast-install" "--build=x86_64-unknown-linux-gnu") <slimjim>so, there *are* some configure flags, but none of the ones I specified <lfam>Yes, but is there a #:configure-flags key? I'm not a Schemer, but I would focus my investigation here <nckx>Those are the defaults (not the ,flags you'd be inheriting — even lower level implicit defaults). <slimjim>so it makes sense that the system isn't picking up the changes I've made to the flags, if they are all getting dropped somehow, because the original definition didn't have a configure-flags section <nckx>lfam: I wasn't following but that's what e.g. (#:configure-flags '()) is for — it falls back to '() if gdb lacks that keyword. <slimjim>ah, yes and original gdb definition does lack that keyword <nckx>Sorry, (#:configure-flags flags '()). <jpoiret>the_tubular: still that gcc patch error? <sneek>Welcome back jpoiret, you have 1 message! <nckx>[reading backlog] git-minimal doesn't use it because it ‘knows’ that git has #:phases, but it's not robust, don't cargo-cult the '() away just because of that. <the_tubular>guix system reconfigugure /mnt/ /path/to/the/config.scm right ? <nckx>One of those is wrong but I lack context to say which. Do you mean to init or to reconfigure? <nckx>It's ‘guix system init FILE TARGET’ but ‘guix system reconfigure FILE’. <nckx>That's the TARGET above. <jpoiret>i have to get some sleep, but you're in good hands here anyway. Good luck <nckx>It is conventionally /mnt. <nckx>Oh, I was also just leaving. No fair. *nckx hopes l fam or so is still around. <jpoiret>oho. well, don't just assume I was (only) talking about you :) <slimjim>I'm getting the same syntax error after doing both a guix pull and a sudo -i guix pull to put me on current master commit b4ee524e5adb2153a0de607a32100a8db2b12585, just to be sure <lfam>Anyways, this is why I don't use inheritance :) <florhizome[m]>unmatched_paren you might really want to leave the sanitizer thingy <nckx>I didn't mean to imply that at all, but there were no other nicks in my screenful. <nckx>I'll try to help continue the gdb-multi debugging when I get back in about half an hour. This ‘can't’ be that hard. <lfam>Yeah, this would be trivial for a Schemer 