<nckx>OK, let's se—oh, that was easy. <alextee[m]>is it possible to make the result of `guix pack` lighter? like removing unnecessary things <alextee[m]>i see alot of unused things in there and im thinking to manually remove them <alextee[m]>pkill9: gnu/store/57xj5gcy1jbl9ai2lnrqnpr0dald9i65-coreutils-8.32/bin <nckx>alextee[m]: What depends on it? <pkill9>is that all the build-time inputs? <alextee[m]>nckx: idk, im just doing guix pack -RR -S /opt/zrythm/bin=bin -L . zrythm-next <nckx>Some (transitive) dependency of zrythm-next keeps a dependency on coreutils. Not surprising to be honest, it's not seen as a problem because ‘you'll have it anyway’. But I agree for packs it makes little sense. <alextee[m]>i guess the only solution is to manually clean these? <alextee[m]>i want to make omni-installers but i can't ship 200 mb worth of crap :-) <alextee[m]>well, crap = useful stuff that's just not needed at runtime <nckx>It's the quick & dirty solution. The right solution is finding out who's depending on coreutils & why. <alextee[m]>even dependencies that are actually used, the might have stuff in their store that's not needed <nckx>And since you're technically breaking the dependency graph (because ‘you know better’), you get to keep the pieces if it breaks 😉 But you're okay with that I'm sure. <nckx>‘guix graph --path’ is *mwah* *makes kissing gesture* <nckx>guix graph --path zrythm coreutils: zrythm depends on xdg-utils which pulls in coreutils. <alextee[m]>i think you're looking for this which actually doesnt render on my machine <nckx>Forsooth, an emojo I don't have. <nckx>I'm deliberately using an older emojifont which lacks most of the fancy 3-byte ones ☹ <alextee[m]>i guess i can remove a few dependencies and use a different version for packing <alextee[m]>i assume every target system will have xdg-utils anyway <KE0VVT>I wish GNU/Linux still had an emoji input tool similar to the Super+: shortcut in Windows 10. Fedora used to have it. <nckx>If you look at <xdg-utils>/bin it's quite obvious why the dependency's there: lots of shell scripts. <nckx>And shell scripts are made of puppies and coreutils and pain. <nckx>KE0VVT: Any idea what it was called? <nckx>alextee[m]: You could use customised versions of each dependency you think is bloated. Not ideal but that's the Guixiest answer. <nckx>‘Typing Booster’ — we should be able to figure out its non-marketing name with that 🙂 Thanks. <mbakke>nckx: oh, nice fix for the totem issue, I had expected some serious substitute* surgery :P <nckx>KE0VVT: It's extremely maintained. We have working ibus. Go for it…? 😇 <KE0VVT>alextee[m]: But you said GNOME has something similar to Windows' emoji input box? <alextee[m]>if you open gedit and type ctrl + ; an emoji selector shows up <alextee[m]>it might be a gtk thing, because it only works in gtk apps so far in my tests <KE0VVT>Yes, that looks exactly like the one in Windows 10. Beautiful. <KE0VVT>Oh, it works here in Trisquel, in Gajim. <nckx>Hm, Guix's gedit does nothing. <nckx>Nor does it log anything missing. <nckx>OH YES IT DOES I JUST CAN'T READ <nckx>These are some huge-ass emojos. <nckx>Makes it easy to see what is what. <alextee[m]>mobile-friendly and my huge m onitor has no space problems <nckx>Doesn't work in GTK+-2, but I didn't expect it to. <lispmacs>hi, I'm reading through the blog post on shepherd, but cannot find the shepherd directory on my system <nckx>lispmacs: What's ‘the shepherd directory’? <lispmacs>nckx: it is the place where the init.scm is located, according to our blog post: <nckx>‘located by default at $XDG_CONFIG_DIR/shepherd/init.scm’ <lispmacs>nckx: there is only a $XDG_CONFIG_DIRS defined on my system <nckx>It doesn't exist by default. <nckx>Create and edit .config/shepherd/init.scm. <nckx>It's not ‘where init.scm is located’, it's ‘where you can put your init.scm when you write it’. <lispmacs>nckx: um, so where is shepherd currently getting its configuration info from? <nckx>You're not running a user shepherd or you'd know. <nckx>You'd be executing ‘exec shepherd &’ or similar in your .xsession or similar. <nckx>I think it's not clear (to you and maybe in general; I didn't have time to read the post in detail) that user services != system services. <nckx>There's a system shepherd that runs your system services, and you can run your own instance of the shepherd to do the same for ‘user services’, like, ehm, your emacs daemon (silly example but that's the only thing I use it for). <nckx>The user shepherd isn't handled by Guix at all, it's something you configure to start when you log in, and that's desktop/whatever-dependent. <alextee[m]>TIL about user shepherd. so it's like a service manager for the user? <nckx>I hope my hurried explanation was of help, please do file a bug (ideally with suggestions for improvement) if the blog post was genuinely unclear. <nckx>And yeah, reading the first 2 paragraphs it does seem to jump straight in. <nckx>alextee[m]: Think systemd --user, if you know that (I don't but it seems to make it click for systemd people 🙂) *alextee[m] has no idea what systemd does \o/ but thanks <lle-bout>nckx, speaking of systemd, my GNU Guix system has a /run/systemd mount, weird <lle-bout>I'm guessing dbus or something must hardcode that somewhere <lle-bout>also, I got GNOME's gdm so that can be it too ***catonano_ is now known as catonano
<str1ngs>sneek: later tell guix-vits. that's the thing about art it's open to interpretation :P <marusich>The only big question I have about the changes is: where did the change to glibc-ldd-powerpc64.patch come from? did you author it, or is it from somewhere? <arpunk>Hello everyone, is there a reason why racket on guix is using the regular variant instead of CS? <lcatcat>Oops, the plugins in my icecat won't work after guix package -u, how should I fix them <lle-bout>marusich, besides that, I quickly ran into an openssl compilation error where I cherry-pick my old commit about the issue to fix it <lle-bout>and then, I'm still waiting for the compilation to finish; specially running $ guix install hello - after having run $ guix build hello <lle-bout>marusich, about the glibc patch, I basically copied the x86_64 one and adapted it. <lle-bout>marusich, nevermind, I simply edited few characters in the original file in glibc's tree, nothing more - but got the idea by looking at what was done for x86_64 <lle-bout>and to be exact, running: $ guix environment --ad-hoc hello <ryanprior>lcatcat: you can roll-back your package update with `guix packge --roll-back` <marusich>lle-bout, OK. I totally rabbit-holed a different thing, and now I'm exhausted, so I don't think I'll have time to work on this today, but tomorrow I'll try to find some time to pick apart that commit into a few individual patches we can submit to guix-devel for review. <lle-bout>marusich, I'm sorry I didnt do that directly, I'm very unfamiliar with GNU Guix contribution guidelines for now <marusich>That's OK. Which parts do you think are necessary for building functional bootstrap binaries? <marusich>e.g. the part that adds powerpc64-linux as a supported platform, is probably not necessary for that <marusich>but, to vet the bootstrap binaries you gotta build something, and to build something, you gotta make it a supported platform, i guess <marusich>point is, I would like to limit the first set of changes to those we believe are sufficient to build bootstrap binaries. Ideally they would be reproducible binaries, and they will work when we follow up with more changes to enable building packages from tem. <marusich>e.g. the parts where you added the bootstrap binaries and their hashes, are not strictly necessary for building functional bootstrap binaries <marusich>I intend to put those into a separate patch series, if possible. <marusich>They like to split changes out to their smallest conceptual purpose, generally. <marusich>going afk now - talk to you more tomorrow! <lle-bout>sneek later tell marusich I was curious what you were rabbit-holing - and to respond - AFAICT the only patch needed on current master to *build* the bootstrap binaries is the one adding: ((string=? system "powerpc64-linux") "/lib/ld64.so.1") - otherwise, to use the bootstrap binaries, glibc and binutils-final changes are required. <terpri>does torbutton in icecat actually work for anyone? it (claims to) connect successfully to the tor daemon, but check.torproject.org says i'm not on tor <terpri>i normally use the tor flatpak but flatpak/bwrap seem to be broken too atm :( <janneke>terpri: it used to work for me, but it broke a couple of months a ago <janneke>since a couple of weeks, the button is gone! <terpri>imo icecat should not bundle it at all, there were good reasons to introduce tor browsers as its own thing <terpri>really need to get back onto facebook (ugh) to track news on local protests, really prefer not to use *that* service from a regular browser <janneke>wow, well if we need facebook, then all is already lost imo <terpri>(or at all, but there is no alternative for me in some cases) <janneke>i aprreciate the reasons for tor-browsers, but i'm a sucker for independent verification <terpri>i'm doing all the organizing i can over signal, but some local comrades refuse / don't know how to use free services <janneke>i dont want to have to trust their binary (that's a real hazard for them too, i believe) <terpri>well, it could be packaged icecat-style <janneke>terpri: it's something we could learn and teach eachother about... <terpri>yes, i educate people when i can (have gotten many people to install signal), but it takes time and my city is on fire <janneke>yes, i don't want to sound too harsh -- but it's difficult <terpri>there would be issues with packaging torbrowser independently though... <terpri>like it would have to be locked into no-js mode, because librejs would lead to browser fingerprinting issues <terpri>(torbrowser has three security modes iirc, one or two are no-js) <terpri>the specific error with all flatpak programs is: "bwrap: execvp xdg-dbus-proxy: No such file or directory" which sounds like it *could* be a simple fix ***apteryx is now known as Guest61121
***apteryx_ is now known as apteryx
<terpri>hmm: "F: Running '/gnu/store/kzq4v5fvjbdbbwah74k10pf698xkbdpr-bubblewrap-0.4.1/bin/bwrap --args 28 xdg-dbus-proxy --args=30'" <terpri>args for xdg-dbus-proxy include "--ro-bind /gnu /gnu" so it's probably a $PATH issue <terpri>args for bwrap running xdg-dbus-proxy, rather <mbakke>terpri: in another bug report we discovered that bubblewrap will not resolve symlinks, so e.g. installing xdg-dbus-proxy into your profile won't work <terpri>mbakke, thanks, that's useful to know <terpri>attempting to get flatpak to use the full path to xdg-dbus-proxy to see if that helps <janneke>hmm, there's a build substitute, but no log file <janneke>bah, --no-substitutes does not carry over to the offload server <xelxebar>Asked this yesterday but went to bed and my logs may have cycled out the answer: <xelxebar>When building with --check --rounds=2 and there's a discrepancy between rounds, sometimes I get two outputs in the store foo and foo-check <xelxebar>The failure message is something like "Outputs differ between /gnu/store/..-foo and /gnu/store/..-foo-check" <xelxebar>However, most of the time, the message just ends "output differs" <xelxebar>What am I missing that's causing different outputs and error messages, and how do I get the *-check one back? <terpri>i fixed it! now to remember how to get this git commit into guix <mbakke>xelxebar: it's a bit confusing, --rounds only take effect with normal build commands, while --check only works when you already have the item in your store (and --rounds does not apply to --check) <mbakke>xelxebar: in in all cases, you need --no-grafts to prevent testing the grafting process <mbakke>as well as --keep-failed to actually save the result <xelxebar>mbakke: Thanks for the clarification. So when does the *-check output end up in the store? <mbakke>xelxebar: when you use --keep-failed <xelxebar>Oh. I see. I had just equated that flag with "keep /tmp/* build directories on failure" *xelxebar ircs mbakke internet cake <terpri>trying to gather my wits to write up a proper changelog message. my city is on fire <xelxebar>e/me wishes cake could abolish this custom build system that's non-deterministically generating C source files <mbakke>xelxebar: what package is that? :/ <xelxebar>xed, Intel's x86 encoder decoder. It's a nifty tool for studying x86 opcodes, but the entire build system is a bunch of custom python that generates a bunch of C. <terpri>mbakke, yes, raleigh, north carolina. tonight the riot police came out in force to gas peaceful protesters <mbakke>terpri: oh my, that's terrible, I wish you the best of luck <terpri>thanks. i'm fine, but the situation is rapidly worsening nationwide <xelxebar>terpri: Holy crap. I thought you were speaking metaphorically... <terpri>i'm quarantined at home nursing a seriously ill roommate, who would be in hospital in any civilized nation, so i wasn't at the protest itself. otherwise i'd have been teargassed or worse <terpri>friend in SF was gassed, cops are using chemical weapons, flashbang grenades, rubber bullets, beanbags, possibly real bullets against peaceful protesters <mbakke>terpri: excuse my ignorance, the riots are protesting police brutality, right? and the police answers with deadly force? <terpri>mbakke, yes, the protests were sparked by the murder of george floyd in minneapolis, minnesota. he was handcuffed and facedown on the pavement, and a police officer, derek chauvin, kneeled on top of him until floyd died, while floyd was begging to breathe and begging not to be killed <terpri>(there are other recent incidents of police brutality/murder, but that's the straw that broke the camel's back) <terpri>people organize peaceful protests, and police come with teargas and mace and other weaponry and attack whole crowds of protesters <terpri>not certain if there's been more "deadly force" just yet, but probably so, they are using "less lethal" weapons constantly on thousands of people <nckx>… ‘good morning’ Guix ☹ … <terpri>there is a memorial site where floyd was killed, a zone of peace with a beautiful mural and flowers and entirely peaceful gatherings of mourners and so on... <terpri>and tonight the police broke into that zone and started shooting rubber bullets at the mourners and at journalists <terpri>there are also agents provocateurs, police or fascists (inclusive or -- fascists are well-entrenched in law enforcement here) escalating things and attempting to incite riots <terpri>twitter blocked (blocked!) one of donald trump's tweets which ended with "When the looting starts, the shooting starts. Thanks!" <terpri>the protests were initially confined to minneapolis but have grown explosively across the entire country, coast to coast <terpri>and our militarized police forces are brutalizing peaceful protesters in almost every major city <terpri>rioting is escalating (as the police continue to incite them) and there are cities with entire blocks on fire <terpri>i imagine Democracy Now! (https://www.youtube.com/user/democracynow , obviously recommending newpipe etc. rather than youtube's proprietary JS) would be a good non-corporate news source for non-americans who want to keep tabs on the situation <mbakke>local media reports that the president blames the riots on "radical left wing groups" which does not sound like he is interested in a diplomatic resolution :-/ <nckx>(Note for non-USians: ‘incitement’ is American for ’shooting at people’. This is not some yelling riot cop on a front page.) <Hugal31>Is there a way to know why guix doesn't look for a substitute? I have a substitue server and a client that authorized this server, and it worked for installing the curl binary, but now when I want to install iotop, it want to build the iotop derivation along with a big number of dependencies, although the derivation is built on the substitute serve <nckx>Hugal31: Guix caches substitute look-ups for a while. If that's your problem, removing your user's ~/.cache/guix/substitute will fix it. <terpri>some of these police actions would be war crimes if this were recognized as a war <terpri>(under the geneva conventions or protocols, can't remember which) <Hugal31>nckx: Thanks, it worked! However I had no ~/.cache/guix/substitute file, I removed /var/guix/substitute/cache (I run guix as root in a docker for my tests) <Hugal31>Is there a way to do this as a parameter to guix or guix-daemon? <guixer>Hej guix! I'd like to configure my user services properly with shepherd. But I don't get why it behaves like it does.. I have set #respawn? #t but if I kill a service process with pkill, the service does not rerun its command. Instead herd status actually tells me that the service is still running. Any hints? <TBC_x>How do you chroot into guix system from another distro? <lcatcat> export CURL_CA_BUNDLE="$HOME/.guix-profile/etc/ssl/certs/ca-certificates.crt" <lcatcat>curl: (60) server certificate verification failed. CAfile: /root/.guix-profile/etc/ssl/certs/ca-certificates.crt CRLfile: none <lcatcat>Does guix have special requirements for SSL? I used busybox to build a minimal system, ready to run guix on it, but the ssl certificate does not work. <janneke>TBC_x: eh, just like any other distro, something like; chroot /mnt /bin/sh ? <TBC_x>I dunno, It's fresh installation, /bin is empty for some reason <mbakke>lcatcat: I assume you have 'nss-certs' installed? do you get that error connecting to any host? <janneke>TBC_x: do you have .../run/current-system/profile/bin/bash ? <guixer>Icatcat: Not sure if it helps, but on my guixsd installation I have /etc/ssl/certs/ where there are lots of certificates installed. The corresponding package is nss-certs <lcatcat>It can be determined that there are no problems with network and environment variables and packages. <lcatcat>I followed the documentation to install and set up ssl <mbakke>TBC_x: you might be able to use /var/guix/profiles/system/profile/bin/bash <guixer>Anyone able to help me out with my shepherd config? <lcatcat>Just now I tried to soft link nss-certs from etc/ssl to /etc/ssl, but it didn't work. <mbakke>tje guixer, does the program you are starting fork, i.e. go into the background? I think shepherd can't notice when it disappears in that case unless you use #:pid-file <TBC_x>Is there something I should be aware of? <guixer>mbakke: some services use make-forkexec-contructor and some the system-constructor. I used & to put some of the commands in the background, that might be the issue.. I'll have a look into removing thos and check out #:pid-file :). thanks <mbakke>guixer: there is also fork+exec-command, but I'm not familiar enough with the shepherd to give good recommendations <guixer>mbakke: make-forkexec-constructor builds on fork+exec-command. what are you using to control user services? <TBC_x>wait, there's nothing in $PATH? <reepca>TBC_x: source /run/current-system/profile/etc/profile <mbakke>guixer: I just use make-forkexec-constructor in my services, but haven't done extensive testing/research <reepca>actually wait, why didn't running /bin/sh source /etc/profile <TBC_x>The system was not properly booted into by the way ***sputny1 is now known as sputny
<reepca>how'd you come by this system anyway? AFAIK the /run/current-system symlink is created at reconfigure-time <TBC_x>I've just ran guix system init in qemu, then pulled the image out <mbakke>TBC_x: try sourcing /var/guix/profiles/system/profile/etc/profile <TBC_x>So, how do I populate /run now? <mbakke>TBC_x: what are you trying to do? <TBC_x>Well, I'm trying to understand possibilities on how to fix my system when I break it (I will break it). In other distros I usually get any live USB and chroot. <mbakke>TBC_x: with Guix, you typically just roll-back, unless you borked the bootloader. <TBC_x>I can't even count of how many times I got my system unbootable due to messed up kernel, intramfs, /etc/fstab or bad libc upgrade <TBC_x>And even rm /bin/rm during slackware upgrade <mbakke>TBC_x: such problems are nearly impossible with Guix, because once you have a working generation it will stay working <TBC_x>Ok, so how is the LVM support going? <janneke>those things hardly ever happened after we got apt list-bugs? <janneke>anyway, many of those skills are next to useless with guix <mbakke>TBC_x: someone posted WIP LVM patches a while back, if you are looking for ways to screw your system that's a good opportunity to get familiar with roll-backs and such ;-) <TBC_x>This is the stuff I'm talking about! *janneke is a great fan for simple single partition drives <TBC_x>I had 8 partitions on 320GB drive once <TBC_x>Watching gparted progress bars is fun *mbakke is a fan of no partition table at all <janneke>hmm, that makes sense -- is that possible? ***sneek_ is now known as sneek
<alextee[m]>idunno, thanks to the /home partition i managed to distro hop quite a lot while keeping my stuff intact (and reinstalled guix a couple of times on the / partition when it broke) <mbakke>janneke: not with GRUB2, but works with syslinux/extlinux as long as your file system don't overlap with the MBR :P <mbakke>also, should work fine with EFI stub kernels <mbakke>I use partitionless disks for VMs backed by LVM to easily resize them <mbakke>nvm, EFI absolutely requires an "EFI System Partition" <janneke>grub should know of course where the file system begins *mbakke 's first sizable contribution to Guix was EFI support :P <mbakke>still haven't written those system tests I raved about all those years ago... <janneke>"younger-humam", am I bad at making compliments <janneke>so...why would someone prefer to use efi instead of disabling it? *janneke knows farr less than they'd like about this sort of thing <efraim>hmm, mupdf doesn't retain a reference to mujs's js_tointeger <mbakke>it's not really possible to disable EFI, all that does is emulate a BIOS layer <mbakke>as for why to disable that emulation I don't know, I just wanted to learn the guts of Guix :P *janneke just alwasy heard efi=fat=ms=broken (memories of editing file tables by hand) + evil (patents) etc <mbakke>one argument for "native" EFI boot is using GPT partition tables, which are more flexible than the MBR layout <janneke>...but i may have just been running /more/ proprietary code (emulation layer) instead of less, all these years <mbakke>I really don't think the added complexity of EFI is a net win over BIOS though... I hope coreboot becomes more widespread. <janneke>mbakke: well, my first big contribution to guix was the mingw cross build ;-/ <mbakke>here we are, ranting about proprietary and insane technologies while implementing them :P <mbakke>alextee: did you get anywhere with the zrythm cross-build? <mbakke>it would be cool if you wrote a blog post about it when you are satisfied :-) <mbakke>perhaps we could have "pack tests" to catch regressions in that area <jonsger>why is qgis never built by cuirass? there are no search results for it. Is it disabled? <cbaines>It looks like qgis has lots of dependencies, and it only takes one of those to fail and Cuirass will just give up <cbaines>So it's scheduled... which means it hasn't failed to build it yet, but it also hasn't tried <jonsger>it's hard to build on my laptop so in the end I'll remove the package <TZander>cbaines: website showing a queue-index next to the 'scheduled' field would be awesome <mbakke>OpenCV, one of the qgis dependencies, fails on Berlin <cbaines>TZander, indeed, it would be nice to know what's going on more than just a status <TZander>absolutely. The CI website is frustrating for me to use, the dependencies would be nice to show (and their status). <TZander>can I search for queued, but not yet build, packages? If so, how? <TZander>For instance, I'm wondering what happened to the aarch64-linux build of 'master', package flowee. <cbaines>I guess this search sounds like it does what you want: spec:guix-master status:scheduled system:aarch64-linux ^flowee <cbaines>Although I get back builds that don't have that status, so I'm not sure if it's right... <cbaines>data.guix.gnu.org has some information from ci.guix.gnu.org. The advantage of using the Guix Data Service is that it knows how derivations relate to each other, and what derivations relate to which revisions <TZander>ah, indeed. Weird that a normal search doesn't include "scheduled" status. I'd consider that one of the main reasons to use the website... <cbaines>The disadvantage is that you don't know it the data is up to date, and I think it's been stuck updating recently, so it's not up to date <kamil_>Hi! Do we have a CMake pro here? <nckx>I build a bird feeder. Life is good. Yours? <anadon>Catching up on reading, job interview Tuesday, moving Monday. My life seems to be more of anxiety. <anadon>I'vebeen reading therough "The Art of Unix Programming" <butterypancake>what's the state of using npm and/or yarn on guix? I'd like to package signal-desktop but if npm and/or yarn isn't there, it won't be fun... From my perspective it looks like they aren't there... <cbaines>butterypancake, I looked at this recently as well for Grafana, I think there's quite a bit more work needed <cbaines>There has been some work on importers, but I think more is needed <nckx>Hm, seems that our node package is now broken. <cbaines>Hopefully with some progress there, we can get some of the common required packages in to Guix *nckx clears cached failure and tries again. <butterypancake>well, who really liked web dev anyways? Do we really need it? Time to convince all my friends to switch to GNU Jami am I right? <cbaines>I'm still very up for working on this area, just need to find the time <cbaines>I lost yesterday working from 9am to 9pm on work stuff, that root certificate expiry that caused a few problems yesterday <butterypancake>I once spent 3 months doing web dev. Most agrivating point in my life. Imma just sit back until someone else has delt with it <anadon>Looks like repology's entry for guix's `ascii2binary` package's homepage being dead is wrong. I wonder what's going on with that. <cbaines>anadon, I believe the data comes from guix.gnu.org/packages.json <anadon>Yup. Got that, and the homepage link works. Repology says it doesn't. <butterypancake>nckx, mbakke, thanks so much for reviewing my code! It is very satisfying to see my name in the commit logs :D <anadon>Then what is it complaining about? When I type in the URL, it works. <nckx>butterypancake: You've made it! <nckx>anadon: I know, same here, I was just pointing out that it's not even internally consistent. 😛 <anadon>I opened a github ticket about it. <anadon>That may fix a considerable number of "problem" packages. <nckx>anadon: …that was fast. Thank you. <mbakke>butterypancake: I take it you are Morgan? :-) <butterypancake>Yep! Maybe one day I'll use a proper username but until then I'll stick with my cringy childhood one :P <butterypancake>oh, this was back when I was installing guix right? That was a rough time <mbakke>one month from noob to contributor, not bad :-) <alextee[m]>mbakke: i ended up using msys2/mingw..that's cool about the libGL thing! what about the fonts? would i still need to hack it a bit to use cantarell/dseg? <mbakke>alextee: yes, fonts need a bit of hacking, but nothing insurmountable :-) <mbakke>cool, happy to help with the fonts <TZander>guix could use a installation-guide for people using it on a host-OS. Something simple to allow me to run something like inkscape from guix. <TZander>fonts and other such issues should be addressed there <TZander>maybe if you manage to get it running (I haven't) then that would be a nice contribution :) <TZander>mbakke: in guix there are dependencies in 3 forms, native inputs, inputs and propagated-inputs. Why would you ever want an input not be propagated? <kamil_>Where do I make package requests? <TZander>The KDE packages would be so much more maintainable if all inputs were propagated inputs. <cbaines>propagated inputs usually lead to maintainability problems, given that they increase the interactions between different packages in profiles <TZander>cbaines: you mean like two apps using a .so file with the same filename? <TZander>I'm not sure if I can imagine what problems this solves... <nckx>But it's not like everyone checks that page weekly. <butterypancake>so for packaging, how free does a program need to be? Is open source good enough? Texas Instruments releases a bunch of opensource code but they don't really care a lot about licencing to the point that I'm not quite sure what the license on tilib even is <nckx>Then it's not open source. <nckx>Open source == open source licence. No licence == all rights reserved. <butterypancake>:/ If I have to message TI to find the licence I'll be upset. They never respond :/ <nckx>butterypancake: But where's the actual code? <butterypancake>oh dear, that page says the patches to make it compile are all rights reserved <butterypancake>he mirrors slac460y.zip there which is the source code and he has a patch to make it compile <nckx>Eh, I was just typing that the patches are explicitly BSD-2 according to the ‘License for patches’ section on that page. <mbakke>TZander: in what way would propagation help maintain KDE packages? <TZander>butterypancake: halfway down the page there is a BSD-2 <TZander>mbakke: removing the massive duplication of inputs <vagrantc>"all rights reserved" is not mutually exclusive with licensing ... they're separate concepts <TZander>mbakke: making it more in line with normal expectation that if you depend on a lib, you automatically pull in its dependencies. <TZander>mbakke: the vast majority of those packages are dynamic libs, why ever would you not propagate them? They are always needed at runtime. <nckx>vagrantc: Well, in the sense that ARR is the default and a licence is always required to do anything with the code: sure. <mbakke>TZander: why would you propagate them? the dependencies are encoded in the .so files, you can run almost any executable directly from the store without installing to a profile <mbakke>propagation obscures the dependency graphs <nckx>butterypancake: That ZIP file looks free but I didn't check every file. <TZander>mbakke: why would you? Because stuff won't compile if you don't pull in all dependencies of a lib you depend on. <mbakke>if package A depends on qtsvg, it should have qtsvg in inputs, even if package B propagates it <mbakke>TZander: but that's what we currently do? <TZander>To avoid having qtsvg in its inputs, I mean <TZander>Why would you force a packager to mention each and every KDE package that it pulls in Qt? <mbakke>Guix would lose its "world view" if we were to propagate things that are not needed <TZander>almost always. Maybe in the case of staticly linked libraries they are not <TZander>whats wrong with making 'kio' tell the world it depends on QtBase? <TZander>That means that if in the future kio also depends on another package, you don't have to go and update the dozen packages that depend on kio today in order to continue making them compile <mbakke>the world already knows it depends on qtbase, but the rest of the world might not <butterypancake>what license would I put for tilib? It's a BSD-2 + don't use TI's name to endorse your product made with this unless we say that's cool <TZander>mbakke: do you think it is a feature that you have to manually have to add all dependencies of libs 2 or 3 layers deep? <mbakke>TZander: no, that's not how Guix is supposed to work <mbakke>it is possible that some KDE packages needs to propagate some of its dependencies, but propagating everything is very wrong <mbakke>TZander: look for instances of propagated-inputs in Guix, almost every instance is accompanied by a comment that explains why <TZander>this makes guix behave different from what every developer expects to happen, I think its useful to know why <mbakke>TZander: I already explained why: it obscures the dependency graph, we'd lose control over which package depends on what, and it would massively bloat your package profile. <nckx>butterypancake: Can you link to the exact text? <TZander>mbakke: I don't understand how making the dependency graph, in simple terms, exported is the cause of obscuring it. How can you argue that? <TZander>If I now package a new app that uses kio, guix is not helping me find the dependencies. <TZander>I need to **manually** look them up. How is that helpful <mbakke>TZander: that might be a bug, dunno <mbakke>TZander: if you package something that depends on kio (only), and adding kio in inputs is not sufficient, then that is a bug <nckx>butterypancake: Oh, that's just a 3-claude BSD licence (bsd-3). <mbakke>that means something should be propagated somewhere <TZander>mbakke: yes, which is the case in 99% of the KDE packages <TZander>mbakke: that is how header files work... <mbakke>TZander: indeed, and if you look for instances of propagated-inputs, you'll find a lot of "used in public headers" etc comments <TZander>I mean, the kde.scm mentioned 80+ times qtbase for a reason. <cbaines>Do you have an example of a KDE app to try TZander ? <cbaines>TZander, Ok, how do I try out krunner? <cbaines>The package description makes it sound like something you'd use for developing KDE apps <TZander>cbaines: you can start it on the command line and hit alt-f2 (or alt-space) to get a commandline to quickly launch stuff. <nckx>butterypancake: It'll come naturally soon enough. <TZander>cbaines: but if you want an end-user app, try krita <TZander>cbaines: notice how the list of inputs is quite long. If you trace them then the majority are actually inputs of inputs. <TZander>So, each time you package a KDE app you have to reinvent the wheel because guix hides the dependencies. I don't understand why you want that <cbaines>at least in my mind, generally you want the behaviour of a store item to be fixed at build time <cbaines>and that requires tightly controlling the dependencies <cbaines>sometimes you want to not do this, and that's also OK, when there's a good reason <TZander>can you explain whay you mean by "tightly controlling the dependencies" ? <cbaines>Say you have a program written in Guile, and you install it <cbaines>if it propagates it's Guile dependencies, then these show up in your GUILE_LOAD_PATH in your profile, potentially affecting the behaviour of other packages <mbakke>TZander: do you have an example package where you have to add indirect dependencies as inputs? <cbaines>whereas, if you tightly control the dependencies, and fix the GUILE_LOAD_PATH used at package build time, and don't propagate the dependencies, then that won't happen <TZander>mbakke: krita adds qtbase as a simple example <TZander>cbaines: I don't know guile, is it an interpreted language? <TZander>so maybe the rule is relevant for guile, not so much for most compiled stuff... <TZander>If I have a c/c++ library, and one uses Qt (as a simple example) there isn't anything I can do to make anyone trying to compile that NOT also require Qt. Since it needs those headers and it needs to have the .so's to link. <cbaines>If you're talking about things like libraries, then they should be handled differently, and it's quite normal to propagate dependencies <TZander>yeah, I would suggest propagation to be the standard for all libraries. Maybe not for apps (where there are no .so files installed) <cbaines>So, taking krita and qtbase as an example, does krita directly stuff provided by qtbase? <cbaines>If it doesn't, then there's an argument to removing that input, and doing something else <TZander>krita has C++ code that includes headers from various KDE libs, and those inherit from (and thus include) header files from qtbase. At link time and at runtime they use the dynamic libraries from qtbase <cbaines>I've just tried building krita without qtbase, and I got an error which suggests the karchive package should propagate qtbase <cbaines>there could be others, I just looked at one error <TZander>cbaines: and karchive is used by kio. So maybe kio should propagate karchive <butterypancake>in the synopsis for tilib, should I put something like "You'll likely want to install the MSPDebug package to use this" and also put a thing in the MSPDebug package saying "If you are using X probe you'll want to install the tilib package"? Do we put suggestions in the synopsis? <cbaines>and if karchive is required when using kio, then propagating it would be good <TZander>cbaines: yeah, so maybe kio should propagate karchive <cbaines>kio already propagates some similarly named things <TZander>yes, this is what you'll see almost all the time in C++ libraries <TZander>I'd argue that it should be default (to avoid lots of work) unless there are issues <guix-vits>butterypancake: probably in description, as synopsis should be short? <sneek>guix-vits, you have 1 message! <sneek>guix-vits, str1ngs says: that's the thing about art it's open to interpretation :P <cbaines>TZander, there isn't really a default here, just two lists <cbaines>TZander, feel free to send patches if/when you notice issues like this, it should be as easy as just moving the input from the inputs list to the propagated-inputs list, with the justification that it's required at runtime to use the package <TZander>cbaines: maybe best to start with a comment and an awareness that propagated inputs are just fine in all libraries. <TZander>It would help immensely if this is accepted to avoid having to have a justification. The justification is: its a library. This is how libraries work. <cbaines>I'm not sure that argument generally applies though, the other inputs to karchive are zlib, xz and bzip2, and I'm not sure all of those are required to be pushed in to the profile where you're using karchive <cbaines>just because it's important that some inputs are propagated, doesn't mean it's best to propagate all inputs <guix-vits>butterypancake: We do put suggestions in descriptions: for example in `hackrf` <nckx>butterypancake: If there's a 0% chance of either being useful on its own, consider a dependency (but only then). If it's around 2%, a note in the description is warranted. <guix-vits>butterypancake: also tor directly suggests installing `torsocks`. <nckx>guix-vits: Yeah it's absolutely fine 🙂 <mbakke>cbaines: great summary of the situation, I got rather triggered by the notion of propagating everything all the time :P <cbaines>thanks, I think looking at specific examples helps <butterypancake>tilib is needs for mspdebug iff your using a ti probe. so tilib would be an optional dependency if at all. But I think some other programs use tilib so I'm thinking they should just be two seperate packages? <nckx>Even if nothing else used it that would be the case. <TZander>mbakke: why would you NOT propagate things like bzip2? <mbakke>TZander: a plain install of Guix System does not even include glibc in the profile, much less things like Perl or Python, and I prefer it that way <cbaines>TZander, I guess one reason is that it's unnecessary <cbaines>If you look at the linking for the so file in karchive: ldd /gnu/store/kk1id0wsyh6d4sfrikwhqiqwrwvg8h2x-karchive-5.63.0/lib/libKF5Archive.so.5.63.0 <TZander>mbakke: size? They are still on your system. <cbaines>Then you should see it links against libbz2 with the full store path <mbakke>TZander: glibc maybe, not necessarily perl or python (often just build-time dependencies) <cbaines>So there's no need to propagate bzip2 <TZander>yeah, those are native, obviously perl is not a dependency of an .so ;) <mbakke>TZander: to flip the argument, why would you want to pull in bzip2 in your profile just because you install something that links to it? <TZander>Loads of stuff in /lib I have no clue about <cbaines>If you want to have a different version of bzip2 in your profile, that library unnecessarily propagating it will get in the way <TZander>I think we have .so versioning for that <TZander>thats what other package managers use <cbaines>The bzip2 package has a bin/ directory <apteryx>TZander: keeping a profile as clean as possible is nice for the functional model. It helps avoiding unexpected interactions between the applications that share it. <TZander>apteryx: yeah, for binaries and modules like guix that makes sense. As explained before by others. No doubt. <mbakke>if you want a custom build of libfoo, let's say with -march=native, it would be difficult to use it in a profile if other packages needlessly propagate the vanilla libfoo <TZander>when it comes to libraries (and indeed, bzip2 is a gray area because the package has both) I don't see it. <nckx>TZander: That would make it impossible to combine two packages that link against 2 different builds of libfoo into the same profile. <TZander>OK, how is this. All libraries always propagate their dependencies. (like kio propoagates karchive, and someone propagates qtbase) and applications (like krita) then have to have MUCH less inputs. Apps don't propagate anything. Nothing ends in the profile. <nckx>How does that address any of the objections? <TZander>Which objections does it not address? <TZander>It stops having any effect on the profile, it helps making things much more maintainable <apteryx>how does propagating inputs for libraries mean having to specify less inputs for an application of said libraries? <TZander>apteryx: an app like krita now has to repeat lots of inputs of the libs it uses. Flattening the dependencies of 3 or 4 layers all into the krita package. <cbaines>we've already established though that the problems with krita can be addressed <mbakke>IMO propagating-by-default makes things less maintainable, because you can't be sure whether removing an input of Kio will dependent packages (that may or may not use it directly, you don't know) <apteryx>yes, you shouldn't have to specify transitive dependencies of librairies of a package using said libraries. If you do, there's a problem with those libraries. <TZander>apteryx: agreed, the issue is that the majority of the KDE libs violate that logic <TZander>mbakke: the converse is now true, your libary adds a dependency and you have to go and fix all users of that library. Not all of which may be inside the guix repo <mbakke>TZander: as apteryx said above, you don't have to add transitive dependencies to "end users" <TZander>If I read you correctly, then we agree. <apteryx>is there an issue # about this KDE libraries problem? <TZander>I think this addresses the issues: All _libraries_ always propagate their dependencies, which are libraries too. (like kio propoagates karchive, and someone propagates qtbase) and applications (like krita) then have to have MUCH less inputs. Apps don't propagate anything. Nothing ends in the profile. <TZander>apteryx: it would be unproductive to file a bug stating "we have 80+ copies of the qtbase input in the kde.scm file". I can file it with the proposed solution if people think the suggestion makes sense. <mbakke>TZander: it does not address the issue where krita _directly_ depends on libfoo, which happens to be propagated by libbar, and removing libfoo from libbar would break krita <nckx>nixfreak: It's part of node. <nckx>nixfreak: We'll see; it might not do as much as you expect 🙂 (or it might work fine for your use case). <nixfreak>I need to install antora which has dependencies in node using npm <TZander>mbakke: If you write a cmake parser to find all the **direct** dependencies of an app, you can add that libfoo to the inputs of krita. <TZander>otherwise I'm thinking you are searching for problems in order to avoid having to face that there is a massive duplication of effort that has piled up in the packages of guix <mbakke>TZander: surely isolated to the KDE packages <apteryx>the golden rule has so far been to propagate only when it is required. Without digging in, and knowing that KDE is C++ based, I can only guess taht the problem with KDE libraries is that *some* (constrast this with *all*) packages should have been propagated but haven't. I'm not a KDE person, but it seems unnecessary to unilaterally recommend that libraries always propagate their dependencies. <mbakke>TZander: if you can point out a single non-KDE package with this problem I will be surprised <nixfreak>npm WARN checkPermissions Missing write access to /gnu/store/7ijpp79zv5fzpgnsbxinn1a5xzlnh4d5-node-10.19.0/lib/node_modules <nixfreak>bummer do I have install node via root then? <nixfreak>I tried sudo and still got the permission issue <nixfreak>would it be better to setup a new profile and then add it there? <cbaines>nixfreak, you can put something like prefix=/home/chris/.npm-packages in ~/.npmrc <cbaines>then npm will install to your home directory <nckx>TZander: I find your attitude quite inappropriate. You refuse to listen to the many objections to your (flawed) proposal then top it off with an accusation that others are making up objections in bad faith. Do with that information what you will but it just might explain why you haven't convinced anyone. <nckx>Perhaps a calm and considered mail would be more effective. <efraim>sefault in ly when I try to use it at boot <TZander>mbakke: I can take the challange to find another app. Inkscape has libpng as input. It also has freetype as input which has libpng as (propagated even) input. <mbakke>TZander: inkscape does seem to directly depend on both though <TZander>mbakke: ok, here is another one. Libreoffice depends on boost. It also depends on libcmis which depends on boost <mbakke>TZander: libreoffice depends on boost all over the place it seems <mbakke>also, I'd appreciate if you grep the sources yourself instead of having me do it :-) <TZander>What do you mean inkscape doesn't depend on them? Is the packaging wrong? <TZander>you lost me... Why are these examples of what 'guix edit' shows not examples of how the number of inputs would be lower if libraries propagate libraries they depend on? <mbakke>TZander: inkscape does '#include FT_FREETYPE_H' and 'png_create_write_struct(PNG_LIBPNG_VER_STRING', why should it not have freetype and libpng as inputs? <TZander>because that is how c/c++ library dependencies wokr... <apteryx>Are you arguing that every libs on Earth should appear under /lib and packages would find them automagically by side-effects without explicitly specifying them? That is starting to sounds a lot like what most distros do. Guix does it differently though, and I think it's a good thing. <TZander>no, its not how distros work, its how dynamic libraries work <TZander>do an 'ldd /usr/lib/libfreetype.so' and notice the output has libpng in there. <mbakke>TZander: that does not mean that every user of libfreetype needs libpng.so available <TZander>remove it and notice how your application will no longer link <TZander>unless you just ignored the previous conclusion that libraries should propagate libraries, and apps should not, then you are just wrong. <mbakke>TZander: well, in the case of libfreetype.so specifically, you are right, and which is why libfreetype propagates libpng <mbakke>it does not logically follow that inkscape should not have libpng as an input <nckx>mbakke: TZander misread your ‘does’ as ‘doesn't’, which explains much (but not all) of what followed. <apteryx>nckx: very interestingly, the middle click paste issue came back to haunt me (until the next reboot, I guess). <TZander>"that does not mean that every user of libfreetype needs libpng.so available" <-- this is demonstrably wrong, 100% of the applications linking against libfreetype need libpng in the container in order to compile. <nckx>😃 (Not laughing at you, but at the sheer *tenacity* of this thing.) <nckx>So it was mouse-independent, ja? <apteryx>nckx: yes, I thought for a while my mouse had a hardware issue, but it doesn't, and it affects any mouse. <nckx>I'm tempted to think it is a hardware issue, just not on that side of the connection. <nckx>Mainly to preserve my belief in a deterministic universe, but still. <nckx>Or you have some weird forgotten Xorg.conf you're not telling us about. <apteryx>TZander: the only reason freetype propagates libpng is to not break pkg-config when it's used in build systems. The comments says: "These are all in the Requires.private field of freetype2.pc.", when referring to libpng and zlib. <lle-bout>hey, there's no lightdm service, how are we intended to use lightdm in GNU Guix? Or one just needs to contribute a service? <nckx>lle-bout: It's currently in flux, so I'm not sure, but it is being worked on. <lle-bout>nckx, okay, GDM has been too RAM hungry for me *nckx excitedly remembers that logs.guix can search now. <nckx>So probably still in ‘how do we DTRT’-limbo. <apteryx>TZander: if you 'info "(guix) package Reference"', you'll find the common uses of a propagated inputs detailed in the documentation of that field. <apteryx>quote: For example this [propagating an input] is necessary when a C/C++ library needs headers of another library to compile, or when a pkg-config file refers to another one via its ‘Requires’ field. <mbakke>TZander: take qtbase for example, 'ldd libQt5Core.so.5.14' will show heaps of libraries, but applications such as wpa-supplicant-gui link it just fine without those being propagated <apteryx>mbakke: do you think I can push Inkscape 1.0 to staging? <nckx>lle-bout: Thanks for the link. I want to re-evaluate my somewhat unfulfilling workflow & try some new stuff when I finally switch to Wayland, so it's very welcome. <mbakke>apteryx: no, staging is currently frozen <nckx>…and staging-next is/was a trap. <mbakke>apteryx: but you can push it to master, by adding a inkscape-1.0 variable <mbakke>staging-next is broken indeed :/ <lle-bout>nckx, I used sddm previously for Wayland with Sway and XWayland, but it seems SDDM runs in Xorg so there's both running in the background, so I removed SDDM entirely and started Sway from the command line directly. <apteryx>haha, ok. Hm, I'd rather get rid of the old inskcape, as inkscape 1.0 is (supposedly) much faster when invoked to transform images at the command line. <mbakke>apteryx: you'll have to wait for the next staging cycle in any case, by pushing to master at least users can start enjoying the new version :-) <mbakke>apteryx: as a bonus, your friendly local staging herder will probably take care of getting rid of the old version when it is time <butterypancake>how do I clear the cache for a package? It's having trouble unzipping a zip it downloaded so I want it to redownload the zip. The GC options don't seem to mention being able to specify a package. I see the option to remove the zip directly, but I'd like to clear everything related to this package <butterypancake>also if anyone has experienced zip problems recently, I'd like to hear of those because I'm prety sure my downloaded zip is fine :/ <mbakke>butterypancake: is the zip file a 'zipbomb' by any chance? <nckx>butterypancake: Whoah there, X-Y-Z problem I think 🙂 You can force a re-download of the zip file by changing the hash by one character, but that will just redownload the zip. What's the actual error? <mbakke>i.e. does it have all the files directly at the "top level", instead of inside a subdirectory? <butterypancake>so it says command "unzip" "/gnu/store/xxxxx-MSPDebugStack_OS_Package_3_15_0_1.zip" failed with status 127 <butterypancake>but if i manually run unzip than it works. So maybe it doesn't have the unzip exe? <mbakke>then you need to add unzip as a native-input <butterypancake>shouldn't it do that for me? I didn't ask it to unzip, it magically knew that <nckx>butterypancake: Maybe, but it doesn't, stop asking questions 😛 <nckx>😃 Sorry. butterypancake: It's because unpacking happens during the *package* build, not the *source* build, and so the source would somehow have to influence the package inputs (ehh, probably nasty) or we'd have to add ‘unzip’ as a default input and where will that end. <nckx>…in one extra input, that's rig—I mean madness! <butterypancake>Now it's saying no makefile found? I'm so confused by this package. I create a guix environment and goto the folder and run make and see that it's supposed to complain that I don't have boost, not that the makefile doesn't exist... <nckx>butterypancake: It *is* a zipbomp (Makefile is in the root directory, not nicely in MSPDebugfoo-x.y.z). Use url-fetch/zipbomb instead of url-fetch. <nckx>If you don't, Guix playfully decides to chdir into the first directory it finds. <butterypancake>oh, I get it. a zipbomb is when you make the zip wrong and ruin my entire day <nckx>Weeell, it's not conventional, but it's (could you guess?) a lot more common in Windows World®. <nckx>OK, this says OSX, but it's still a filthy zip file. <nckx>butterypancake: The ‘jump into the first subdirectory you find’ behaviour isn't *good*, it just happens to work slightly more often than not so it's the default. <nckx>So you think ‘wow, Guix figured out the structure of my tarball all by itself, it must be using AI’ and you buy more Guix. <butterypancake>If you make me a zip that doesn't just contain one folder, it will all be strewn across my home directory and I will be mad at you. This is one default that I won't fight you on. <butterypancake>ugh, they put #include <hidapi.h> instead of #include <hidapi/hidapi.h>. Why you gotta make my life hard? <butterypancake>is there any reason why hidapi.h is located in a hidapi folder? Seems kinda silly to me. I'm currently struggling to get the include path to go inside the hidapi folder :/ <nckx>butterypancake: It's not our decision, that's all I know. Just use substitute*. <nckx>I think <foo/foo.h> is considered ‘cleaner’ but these things are as subject to fashion as anything else. <butterypancake>I was afraid you'd say that. I should probably just apply this random dudes patch to it. Does the gnu-build-system have a patch phase? <nckx>butterypancake: No, it's part of the source field. (patches (search-patches "foo.patch")), put foo.patch in gnu/packages/patches, add the patch file to gnu/local.mk (under dist_patch_DATA) — alphabetically of course. <nckx>I strangely didn't see any patches for Debian's mspdebug package, though I didn't look that hard. <nckx>It's also insanely out of date. <butterypancake>I'm working on tilib now, an mspdebug plugin thingy. But it looks like TI actually calls it the "msp-debug-stack" even though you can debug msp without it <butterypancake>I don't think anyone actually packages tilib but I could be wrong <nckx>Uh oh, license=('custom')? :-/ <nckx>Let's hope it was just a lazy packager. <lle-bout>I'm feeling so handicaped writing Scheme in Emacs.. <nckx>butterypancake: I don't pretend to understand anything about these packages or their versioning. <butterypancake>lle-bout: bruh, if you figure out how to write scheme in Emacs, let me know immediately. I'm not having a fun time <butterypancake>oh, I see how it works. the AUR version just installs the precompiled binaries. very lazy packager <butterypancake>oh, apparently the patch isn't from some rando. It's from the creator of MSPDebug. I guess I should just do the patch thing then ***bubble01_ is now known as bubble02
***bubble02 is now known as help
***help is now known as bubble02
<butterypancake>so I put 'command -v shepherd && shepherd' into my .profile so I could have user level services. The problem is that if I login twice, now I have two shepherds both running all my services and my services don't really like that. Also if I don't login, my services don't run (not a big deal really but systemd is nicer in this regard). Is there a solution for this? <butterypancake>oh dear, I think the patch is supposed to be applied one directory higher. Ugh. How do patches work? <rndd>hi! i'm trying to pull guix from my local copy (url "file:///home/myuser/..."). but there is the error "guix pull: error: Git error: object not found - no match for id (5c133ca561acfc1a1b9fe6dfc03d2bd12784242c)" <ArneBab>terpri: I wish you strength to keep going! ***amiloradovsky1 is now known as amiloradovsky
<guix-vits>rndd: idk, totally: but what do `git status` say? Is the local repo updated? <rndd>guix-vits: "On branch master Your branch is up to date with 'origin/master'. nothing to commit, working tree clean" <guix-vits>rndd: maybe `git fsck` (am just saw in Web)? <rndd>guix-vits: nope, it's same <guix-vits>rndd: idk, again: i'm on commit 6dcc17105e1fa86513dc29395a79d789216990b7, and it's working. Maybe downgrade the repo? <rndd>guix-vits: hmm, could you give a tip? should i note commit in channel.scm? <apteryx>that seems like a way to g gf gg x b7mx^&){}Z <apteryx>){60kjx776meta-7meta-6x50r[Kctrl-MZJspace)[5 <apteryx> ){5){JK ){5){JK %){rk j%[rjk 0[5r){{ <apteryx>)00[0505[0[00[0[000[00000[[0[[[[00[0[[[0[50[jx k%){Z% <nckx>apteryx: Cat got your mouse again?