<civodul>nckx: i was thinking of adding it to guix.texi <vagrantc>grafts are only done when the end result comes out identical ... or is that just in theory? <vagrantc>or ... is it more grafts are only supposed to be done when the end result comes out identical? <nckx>vagrantc: May I push .CMAKE_HOST_SYSTEM. → @CMAKE_HOST_SYSTEM@? The wildcards trip the eye, imply something clever is going on, but there isn't. <nckx>The output is indentical. <vagrantc>i had troubles with some characters and just got in the habit of using . when it won't hurt anything. <vagrantc>there are a handful of those in my recent commits, possibly <vagrantc>i should probably make a habit of getting it working and then reviewing how to escape things if needed <nckx>Maybe it's just me (I *do* have a habit of using ‘clever’ substitute*s), but seeing . made me pause. But the effect is the same, sure. <nckx>vagrantc: The only tricky thing is to use double \\s, except for \", because reasons that make perfect sense once you understand the reasons. <nckx>Before that, apparently, pain, I've noticed. <nckx>Hammers litter the surgery… <vagrantc>i think that's the summary of my recent overuse of "." matches <vagrantc>though there may be more with further git archaeology <vagrantc>i'll try to be more particular en el futuro <vagrantc>nckx: also toss a few crowbars over my shoulder after every commit <vagrantc>brings good luck to those not standing behind me <nckx>* vagrantc then throws some salt over the other shoulder for even more good luck, also screams. <nckx>…it really wasn't that bad, your vtk commit just happened to catch my attention (bad luck). <nckx>I rely on that in others so it's only fair. <FriendFX>Hi Guix, I run guix package manager on top of Xubuntu 18.04 through which I've installed `terminator` and which was working well until today, when it wouldn't start anymore: <FriendFX>gi._error.GError: g-invoke-error-quark: Could not locate g_option_error_quark: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.28' not found (required by /gnu/store/a1vnwxgl18qn30yfl20lm0hrx1n78jvy-glib-2.70.2/lib/libglib-2.0.so.0) (1) <johnjaye>what's the analogue of apt-file in guix? i want to find which package provides openssl command <johnjaye>i suspect it's openssh but i thought i already have that? <nckx>There is no apt-file for Guix. <johnjaye>this might seem obvious. but the /gnu/store prefix for everything is really hard to read in terminal <johnjaye>is there a bash setting to maybe shorten that or something? <nckx>I doubt it. That's not really bash's job. You'd need a programme that allows you to apply custom filters to anything that's printed to your terminal. I don't know if anything like that exists. <nckx>Yeah, something like that. <nckx>Certainly nothing related to bash. <nckx>singpolyma: Any terminal-agnostic ideas? <nckx>(Just as a thought excercise; I don't actually want to imagine dealing with everything that can be thrown at a terminal as a stream of whateverbuffered bytes.) <singpolyma>ls /gnu/store | sed -e 's~([a-f0-9]{5})[a-f0-9]*(.*)~\1\2~' <singpolyma>Probably. I didn't actually try it, but you get the idea <nckx>Try piping htop through that. <johnjaye>the context in this case is top. all the program lines are '/gnu/store/a823489fohafhsdufh...' <singpolyma>It's not really terminal agnostic but could do a screen or tmux or dvtm extension. Put a terminal in your terminal <johnjaye>obviously you want to know what the program at the end is <nckx>I added exactly this function. <nckx>I think it's bound to ‘p’? <singpolyma>In something like top you're screwed because all the characters aren't even present <johnjaye>i see it works but i'm confused. is it that htop was patched specifically for guix to do it? <johnjaye>i prefer simpler tools like top usually since they are installed by default on most unices <nckx>I was actually using Nix at the time. <singpolyma>Could maybe have wrapper scripts that set the display CLI of programs to a shortened version. That would affect ps and top <nckx>Well, you can certainly find or write a filter that can handle top's output and control codes. It would no longer be simple. It would be more complex than just using htop 😉 <johnjaye>the more fundamental issue i suppose is writing scripts or issuing commands <johnjaye>i guess most of the time it's the PID you want anyway though <singpolyma>nckx: I meant that the thing top and ps display is itself customizable right? Like a process can set any string to show up there <singpolyma>Sure. Lots of programs rename themselves to put useful stuff there <johnjaye>i'm partial to commands like killall firefox-esr when i'm low on RAM anyway <johnjaye>so i would need the actual name for that to work <singpolyma>I think pkill -f matches what is shown in ps and top not the "actual command line" <johnjaye>fuser: identifies processes that are using files or sockets. killall: kills processes by name peekfd: shows the data traveling over a file descriptor. pstree: shows currently running processes as a tree. prtstat: print the contents of /proc/<pid>/stat <singpolyma>pgrep / pkill is pretty similar to killall, maybe even equivalent. Has a -f switch to match on the whole displayed name <johnjaye>clearly you'd want to ignore the hash and have a switch to not ignore it <nckx>Every time I try running top I have no idea what it's trying to tell me. Also, ‘everything is red’ is not a colour scheme. <nckx>So pressing ‘c’ is not good? <singpolyma>Maybe praise be to Debian I have never seen top with colours <nckx>Yeah, I think they still ragepatch it (don't quote me on that though). <singpolyma>I mostly like htop but showing every thread by default is sometimes a bit much *nckx knows all the htop keys 💪 <nckx>In case in got lost> So pressing ‘c’ is not good? [in top] <nckx>I'm trying to understand how this doesn't align with pkill etc <KarlJoad>Is support for pipewire as a service-type in the works? Or would I have to hand-roll something? <vagrantc>huh. if you have a substitute server with unpublished keys performing builds ... any substitutes you get from that server would have to match the signatures from one of the other substitute servers... which is kind of proof of reproducible builds (presuming they're not acting in bad faith) <vagrantc>they could just be proxying nar files or whatever <vagrantc>it would be interesting if you could configure "only download signatures" from one substitute server, and "only download packages" from another... <FriendFX>Hi Guix, I run guix package manager on top of Xubuntu 18.04 through which I've installed `terminator` and which was working well until today, when it wouldn't start anymore: <FriendFX>gi._error.GError: g-invoke-error-quark: Could not locate g_option_error_quark: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.28' not found (required by /gnu/store/a1vnwxgl18qn30yfl20lm0hrx1n78jvy-glib-2.70.2/lib/libglib-2.0.so.0) (1) <johnjaye>nckx: i didn't get that. meaning you think pkill is fine as is? <unmatched-paren>FriendFX: looks like terminator is using Ubuntu's libc, but Guix's gtk <unmatched-paren>johnjaye: there have been several feature requests for an apt-file. i guess guix would have to keep track of some "map" with pairs something like "/gnu/store/...-coreutils-... -> bin/ls" that are populated every time you install a package <unmatched-paren>johnjaye: anyway, sounds like you have a system running in a VM now? <johnjaye>now i just have to figure out what all the terms in the manual mean. <johnjaye>eventually i might even figure out what guix is all about <johnjaye>(i tried searching the mailing lists but I couldn't figure it out) <johnjaye>I keep confusing the goal with guile and thinking everything should be written in scheme <johnjaye>because of what i said eariler. if guix is about packaging things. well doesn't that have a definite endpoint? <johnjaye>once you package all the packages... it's done right <unmatched-paren>everything guix-related, except for the daemon which is written in C++, should be in Scheme <unmatched-paren>it also has features to support service management, and a sort of Stow-like thing <unmatched-paren>johnjaye: Nix has NixOS for services and nix-home-manager as its Stow thing <unmatched-paren>although i think nix-home-manager is somewhat less mature and capable than guix-home <unmatched-paren>(local-file "PATH") just fetches a file from PATH and puts it in the store <unmatched-paren>ultimately it's a unified system configuration framework, which of course includes package management <johnjaye>that reminds me, the second chapter of the manual is heavy on commands. like so heavy it basically says to import someone's key or something to gpg sign images. <johnjaye>i guess guix is somewhat informal in that way <unmatched-paren>johnjaye: where? i think that might be to check the binary hasn't been tampered with <unmatched-paren>"If that command fails because you do not have the required public key, then run this command to import it: <Aurora_v_kosmose>Huh. Should I suggest to Debian's Guix packager to add some dispatcher so that the systemd service uses some sort of wrapper to either user /usr/bin/guix-daemon or /var/guix/profiles/per-user/root/current-guix/bin/guix-daemon depending on availability? <johnjaye>unmatched-paren: right but it said to import a gpg from a user 1747181 or something <johnjaye>looked strange being in a manual but idk <johnjaye>sort of like having linus torvalds have linux as his git repo? <johnjaye>but in any event making a version of apt-file would require a new system you say? <unmatched-paren>johnjaye: well, i think it may require some kind of cache to function quickly enough <johnjaye>i think debian just maintains the .deb files right. and those files for each package just have a list of files <unmatched-paren>they're basically just a package record with a couple of guile scripts as their build phases <unmatched-paren>and usually they use (install-file ...) or (copy-recursively ...) to install files to the store <unmatched-paren>but you could use any guile procedure that would allow you to copy files over <johnjaye>hrm. so i can go to debian package page right now and look up nano. <johnjaye>and it says it will have files like /bin/nano, /bin/rnano, /etc/nanorc, /usr/share/doc-base/nano, etc <unmatched-paren>johnjaye: thing is, if you install the nano guix package, *everything* for nano will be under /gnu/store/...-nano-.../* <johnjaye>meaning at present you could only look up 'nano' if you had the nano package installed <johnjaye>now that i think about it bsd is the same way. i don't think there is an analogue of apt-file on bsd <unmatched-paren>it won't create the symlinks that allow you to use the `nano` executable/man pages/whatever <johnjaye>meaning to make it work you'd have to maintain a database of filenames for each package based on that installation? <johnjaye>ok. it's just apt-file has saved me so many times <unmatched-paren>and i suppose guix.gnu.org could provide some web interface akin to packages.debian.org's file list <johnjaye>like today in fact. i was trying to figure out how to turn my tv on and off <johnjaye>the wiki i found said to use a package that had cec in the name. when i looked up apt-file on things that had cec in the names i found a different package that did let me turn my tv on and off <unmatched-paren>(we have CI machines in berlin, germany and bordeaux, france, so we just call the sites berlin and bordeaux) <johnjaye>ah ok so you already agree it would be a good idea. that's what i was trying to articulate <johnjaye>basically. many times a package didn't do what was required. but looking up names found a similar package that did <unmatched-paren>but you can just use `guix build` if you want to know what files are provided by a package <johnjaye>but you can only go that way if that makes sense <johnjaye>going from a regex on what file you need to figure out where it's from <johnjaye>oh another one is finding a certain library dynamic shared object file <johnjaye>like when building software and it says error need libabc.so.5. so you apt-file find libabc.so to find out where it's from <johnjaye>i suppose one could argue that debian already provides the service <johnjaye>so you could just switch to debian, look up your file, then switch back to guix and install it. <johnjaye>right. it's like bsd's ports. just a makefile that fetches source and runs commands <unmatched-paren>there's no way, other than scanning it at the end, to know what's been installed <johnjaye>sure. but it would be silly to make a distributed hash table/blockchain or something so users could share with each other the files from what they installed <unmatched-paren>but not with some kind of blockchain (honestly if guix incorporated a blockchain i would leave) <johnjaye>i've heard of projects like that before. but they never seem to go anywhere <johnjaye>something like "let's distribute the internet over everyone's pc so the only way to censor it is to destroy all communication" <vagrantc>well, the file lists provided by debian are generated *from* the .deb files, you could in theory do the same from guix's .nar* files <johnjaye>i thought they had date set to 1970 so they were <vagrantc>tar archives can be made reproducible... that's silly. <vagrantc>well, actually, the features to make .tar reproducible probably are after nix was started ... i guess that makes sense <unmatched-paren>NAR is the Nix ARchive. First question: why not tar? Why another archiver? Because commonly used archivers are not deterministic. They add padding, they do not sort files, they add timestamps, etc.. Hence NAR, a very simple deterministic archive format being used by Nix for deployment. NARs are also used extensively within Nix itself as we'll see below. <vagrantc>unmatched-paren: i think the functionality to make tar reprooducible was after NIX <johnjaye>> . First question: why not tar? Why another archiver? Because commonly used archivers are not deterministic. They add padding, they do not sort files, they add timestamps, etc.. <vagrantc>although honestly, it's really easy to get .tar wrong, so having a format designed to be reproducible still has some merit <vagrantc>heh. easiest thing to fix reproducibility of python-pybedtools ... was to update to the newest version! <johnjaye>one more question. it seems nix and guix have similar goals. but it sounds like they do different approaches <unmatched-paren>1. nix uses a turing-incomplete DSL, guix uses scheme (turing-complete) which has better abstraction capabilities and is easier to use <unmatched-paren>2. guix has some concept of packages, whereas nix only has low-level derivations <johnjaye>but the guix concept of package is weaker than the debian "everything goes in a file" concept? <unmatched-paren>johnjaye: i'm not sure what you mean, not too familiar with how dpkg packages work <vagrantc>i'm very familiar with debian packages and still don't know what you mean <johnjaye>apt-get downloads .deb files and the installs them <vagrantc>guix downloads .nar files and unpacks them <vagrantc>what's fundamentally differnt is guix packages don't have a bunch of scripts that run and tweak your system during installation <vagrantc>well, one fundamentally difference to .deb <unmatched-paren>yes, guix packages don't modify ANYTHING apart from /gnu/store/...-package-name-... <vagrantc>guix packages are *just* archives, .deb packages are archives + scripts + metadata (dependencies, etc.) ... to really boil it down simply <johnjaye>unmatched-paren: makes sense. that's what stow solves too <unmatched-paren>it also allows guix to handle multiple versions of libraries at the same time, enables rollbacks, and lets updates be atomic <unmatched-paren>johnjaye: yes, as i said earlier, `guix home` is like a more advanced stow in some ways <vagrantc>hrm. my reproducible builds productivity plummets when data.guix.gnu.org is unresponsive ... so useful! <unmatched-paren>(btw, if you want to start using `guix home` you can do `guix home import ~/.config/guix` and open ~/.config/guix/home-configuration.scm, start hacking, and run `guix home reconfigure ~/.config/guix/home-configuration.scm` to initialize your home config) <johnjaye>ah again with the elaborate shell commands. i'll keep that in mind <unmatched-paren>then you should uninstall all your `guix install` packages, so that your entire configuration is managed by that one file <johnjaye>hmm only root has that right. ~/.config/guix <johnjaye>i don't see it with my regular user on this vm <unmatched-paren>johnjaye: ~/.config/guix is where guix gets installed when you run `guix pull` <unmatched-paren>if you install using sudo, it'll get installed to the literal root user's profile <johnjaye>haha ok. so i can run guix pull, guix reconfigure as a regular user? <johnjaye>i'm confused. so what happens if i do 'guix pull' as a regular user then guix system reconfigure as root? <unmatched-paren>guix pull downloads the latest guix commit, then drops it in ~/.config/guix/current <unmatched-paren>(simplified version, there's some more symlinking involved but it's not important right now :P) <vagrantc>you can use the user's guix to run sudo guix system <johnjaye>well. so i can't do the reconfigure command as root? <vagrantc>it's not that you can't, but then you have to run "guix pull" separately for your user the root user ... to no particular gain <johnjaye>i'm already confused. it sounds like you're telling me to do opposite things <unmatched-paren>it's like if you had a foo binary you'd just made with gcc; you can still run `sudo ./foo`, can't you? <unmatched-paren>`guix pull` to update guix, `sudo guix system reconfigure` to update the system, `guix upgrade` to upgrade all your user-installed packages, and `guix home reconfigure` to update your home configuration <unmatched-paren>`sudo guix system reconfigure` doesn't really have an analogue to apt <vagrantc>the analogies to apt fall down pretty fast :) <johnjaye>i suppose i could just run everything as root though <unmatched-paren>i don't think it will actually do anything when you `sudo guix pull` as it'll just update root's guix, not the system-wide guix <johnjaye>yeah but i'm saying why have a regular user at all if i can just be root <unmatched-paren>you'll be manipulating /root/.guix-profile which your user does not have access to <vagrantc>technically guix doesn't prevent you from making bad life choices, no :) <johnjaye>i mean of course you have problems externally but internally as far as updating and building packages <vagrantc>johnjaye: but one of the awesome things about guix is that you can do package management as non-root users! <vagrantc>johnjaye: so it feels just plain backwards :) <johnjaye>i guess. on most unices it's just assumed package management is done by root <johnjaye>like 'sudo apt-get install' just passes the command to root to do <vagrantc>this is different in a great and wonderful way <johnjaye>and even if you build it as a user it doesn't really matter because you still need root at the end <unmatched-paren>johnjaye: wdym by that? with guix or with a regular package manager? <johnjaye>so unless you just run every package from a build folder you have to be root to install it <vagrantc>yeah, guix gives the users the autonomy without root acceess for most things <johnjaye>yes. you can just run 'make' and then run like src/foo if you wanted to <johnjaye>in fact i do that sometimes if i'm just testing something <vagrantc>with guix you can do that in a manged way *vagrantc uses the excuse that this is a slightly less familiar keyboard <vagrantc>ok, well, this is all pointing in the direction of sleep... <unmatched-paren>actually i need to go too. bye! good luck with figuring out guix johnjaye <Guest11>i have some arch-specific linux kernel i'd like to cross compile, but `guix build` fails with the error message "cc: command not found". do i have to include some specific toolchain for that to work or what am i missing? <problems99>so i created a custom package of xkeyboard-config added to a local channel, with a higher version, guix search shows it but not guix system reconfigure does not pick it up in the config of xorg <Guest11>problems99: when you build that package (as root) does it build your new version? <Guest11>i guess `guix build xkeyboard-config` <problems99>Guest11 yes it shows the right version (the one i customized) <Guest11>did you configure your new channel in your operating-system configuration (the one you specify with `guix system reconfigure`)? <problems99>its being picked up by the current system i checked with cat /run/current-system/channels.scm and its there <jpoiret>problems99: the thing is, in guix, apart from the CLI, everything is specified using variables, so just defining a package with a higher version in another channel won't change anything <jpoiret>ie, all the operating-system things refer to the variable xkeyboard-config in (gnu packages xorg) <problems99>jpoiret that would mean i would need to override that specific variable (or xorg) <jpoiret>You could checkout the guix source code itself and upgrade xkeyboard-config there (but that's a big rebuild, there are 3k+ packages depending on it iirc) <jpoiret>Though I don't know if only your wm/Xorg server needs the new xkeyboard-config for what you want to achieve, or if all apps need the new one <problems99>jpoiret cant modules be replaced on the fly without editing the source code of guix ? <problems99>jpoiret shame (monkeypatching is quite common, even though it has a lot of pitfalls) <jpoiret>well you can monkeypatch in a way, but you need guix source <jpoiret>it's not that hard once you check out the git repo, everything is explained in the manual <problems99>i'll give it a try later once i get the basic and earn learn some scheme <problems99>its basically this, a package has its own directory in /gnu/store/package/share/... i want to be able to put arbitrary (i know its not guix compliant) file there but its a readonly filesystem (for a good reason) <problems99>this is more for educational purposes in case this is something i do need if i move my work env to guixsd <jpoiret>since it's been a requested feature on-and-off, i think it'd be interesting to have some way to modularize which layouts are available <jpoiret>but that'd mean adding code to xkeyboard-config to be able to specify an additional location of layouts, maybe via an env variable, or hardcoded to /run/current-system/whereitssupposedtobe <jpoiret>in the long run, it's the way we/you will want <jpoiret>i know it doesn't sound great right now since it needs way more work than monkeypatching <problems99>on the long run yeah allowing configurability of xkeyboard-layout itself is the ideal solution <problems99>how do i know who uses a specific package (be it system or otherwise) ? since a specific xkeyboard-config is being called by xkbmap i want to know who/what installed it ***PrinceMyshkin1 is now known as PrinceMyshkin
<Guest11>problems99: i think `guix graph` should answer that question <jpoiret>mhmmmm, zsh has an additional completion fpath pointing to /run/current-system/profile/share/zsh/site-functions but then since the system guix is very out of date at this point, i can't complete `shell` and friends <f1refly>so, my laptop just switched off without any notice while I used it and now a file that I've been editing with since yesterday and saved 50 times+ on the way has vanished from my home without a trace <f1refly>my /home is on a btrfs and the laptop batter is at 86% <f1refly>i have no idea what the hell just happened and the logs in /var/log/debug just.. stop before showing the new boot <jpoiret>are you on some sort of raid config per chance? <f1refly>any idea how to make sure this doesn't happen again and maybe how to get back the script I've been creating? <jpoiret>weird, plain btrfs should be pretty stable <f1refly>yeah, I used it without issues for years <jpoiret>i've never had a single issue in 4 years <jpoiret>although nckx's bcachefs lobbying has gotten me interested in something else <f1refly>even with the computer just turning off the file shouldn't be gone after saving it a bunch of times <f1refly>I've never seen one of my machines do this ever <jpoiret>did you run btrfs checking commands on the fs? <f1refly>no recently closed tabs or closed windows O.o <f1refly>hopefully my desktop computer made a backup in the brief moment it was turned on today :( <f1refly>i was able to recover it from the nvim swap file <jpoiret>well, btrfs does have some issues apparently <nckx>johnjaye: <meaning you think pkill is fine as is> I wasn't opining on pkill, just asking whether/why top's ‘c’ key isn't good enough for that use case? The whole ‘processes changing their names’ tangent kinda lost me TBH. <ulfvonbelow>is there a way to specify a search-path that includes certain directories only if they contain certain files? From the documentation I assume that if 'file-type' is 'directory' and 'file-pattern' is given, it will look for directories under the files given in 'files' and add whichever of those match. <ulfvonbelow>(that is, whichever of the directories under 'files' match 'file-pattern' would be added to the path) <jpoiret>just reconfigured my whole system on staging, no bugs to report yet! <jpoiret>is the merge still planned soon-ish? <yuu[m]>f1refly: smartctl and memtest86 just in case <nckx>Is there a ‘licence-texts’ or similar package I could use to provide a COPYING file for a package that ships without one? <nckx>Where provide == instal to /share/doc, as is tradition. <nckx>The source has a licence grant so it's not a blocker, but it would be a nice cherry on top. <f1refly>will give it a full run this night yuu[m] <acrow>Has anyone else noticed that while you can download a pdf using the system print dialog in firefox from flatpak the other gui elements for downloading seem to silently fail? I suspect something is missing from my desktop configuration, but kinda want validation to avoid a wild goose chase. flatpak/firefox has that functionality baked in, right? or do we need some helper packages? Say, xdg-dbus-proxy?? <apteryx>civodul: I'll merge the jami service fixes today if that's OK <acrow>I believe it completely worked in the past but my configuration has changed to address other issues. <apteryx>acrow: my understanding/assumptions of flatpak is that it's supposed to be fully contained; hence shouldn't depend on the host much; thus if my assumptions are right your question becomes a #flatpak question <apteryx>rekado: any idea of what's running on 141.80.167.229? <acrow>apteryx: yeah, that's kinda what I suspected. Thanks. <rekado>apteryx: that’s the management IP of node 129. Don’t remember if you have access to the iDRAC for that node. <apteryx>OK! I thought it was node 129 itself <apteryx>and yes, Ihad iDRAC access there, by hopping on berlin <apteryx>retrying it now just to make sure it still works <constfun>Hello fine folks of guix. I'm having trouble getting a graphics card captured by VFIO kernel module. I suspect it has something to do with amdgpu being loaded before vfio perhaps. Can someone kindly suggest which one of these options is applicable to Guix. Is dracut even used by Guix for example? <constfun>just for the card that I want to pass through? Any tips greatly appreciated. PS. Have been using the the OS for over a year and love it. Thank you! <nckx>constfun: dracut isn't used or even packaged in guix, so at least the dracut-specific ‘rd.driver.pre=’ argument is ignored. But I thought initrd-modules would have the same effect. Is the amdgpu driver really loaded in the initrd, before vfio? ***ec_ is now known as ec
<jpoiret>bjc: i've been thinking of a way to introduce some generic modularity mechanisms that would go beyond just the services we have now, that we could use more generally for the initrd/operating-system stuff or even home <jpoiret>since you were interested in adding some support for modifying the initrd code <bjc>jpoiret: do you have any work for it yet, or are you still just thinking about it? <jpoiret>i'm still thinking about a nice interface for it <jpoiret>but i'd like to bounce off some ideas <bjc>i definitely am still interested in doing stuff in initrd/early-init. i've just not had a chance to work on it for a while <bjc>friggin' erc. jpoiret: if you'd said anything in the last couple minutes i missed it <jpoiret>dw i didnt saya anything while u were away :) <bjc>fwiw, i did end up giving up on the idea of doing everything with shepherd. while i could pretty easily add an ‘early-init’ phase that does the pre-rootfs activation, i couldn't figure out a way to segregate parts of the shepherd graph out so that only the necessary things got copied to the initrd <jpoiret>i'm not thinking about the "practicalities" yet, more like an interface to be able to customize things "in-depth" <jpoiret>ie. how the guix services are implemented <constfun>nckx: thank you. I think amdgpu gets modprobed? (i know little about this topic) its not explicitly listeed in my initrd-modules, but vfio is listed before %base-init-rd-modules fwiw *vagrantc wonders how challenging updating glibc to 2.35 will be just to get the C.UTF-8 locale :) <civodul>vagrantc: there's an initial patch for that by zamfofex <civodul>and yes, having that locale will help a great deal <jpoiret>civodul: got my whole system on staging, no bugs to report! <jpoiret>even watched a movie last night with hw accel on <bdju>if I'm applying a bunch of grafts, are my updates probably almost done? or not necessarily? also why is CPU usage so high for applying grafts if I'm not even compiling anything (as far as I know)? <bdju>I wanted to play a video but it lags too much at the moment with updates still going <jpoiret>yes, grafts should be the last step when building (unless guix decides to build something else after, but for `guix package` this shouldn't be the case iirc) <jpoiret>grafts involve a lot of disk IO iiuc <vagrantc>bdju: grafts (in my limited understanding) are basically patching the binaries directly replacing references in /gnu/store ... which is a bit expensive, though hopefully usually cheaper than recompiling all the things *vagrantc keeps forgetting that etc/committer.scm exists <bdju>thanks for the explanation <dmj`>any easy way to use guix on darwin? <sleepydog>unmatched-paren: why do you say never? it's a question of motivation, right? <unmatched-paren>sleepydog: it could happen, sure, but i'm skeptical that anyone will really have the motivation to port it to a platform whose only purpose is to serve as the base for a proprietary OS <unmatched-paren>porting to BSD would probably advance the possibility of porting to darwin, but i still think it's unlikely <sleepydog>ok, I agree, I just wasn't sure if there was some hard blocker other than lack of interest <jackhill>I don't think we're against running on non-free systems, but it's hard to get motivation, and Apple increasingly makes their platforms more annoying to develop for. <jackhill>And depending on use-case, I wonder about the reproducability of running computation on alternet kernels. Maybe a "Guix Desktop" that hands things off to a linux-based VM would help some folks. <jackhill>yep, the plumbing's in place! Would actually be interested in seeing an additional port to a more mature kernel than Hurd to get more real-world reports. <jackhill>unmatched-paren: right, so if my use case is to get researches, say, to use Guix for reproducable research, maybe I want them to run their computations on Linux even if they have FreeBSD workstations. <vagrantc>it's languished a bit lately, but Debian GNU/kFreeBSD demonstrated that it was possible to run the FreeBSD kernel on a GNU userland ... might not be implausible to port such a thing to guix <mitchell>Hello guix, I've noticed there is a directory "/run/systemd" on my guix system. What is the purpose of this folder on a system managed by shepherd? <sneek>mitchell, you have 1 message! <sneek>mitchell, apteryx says: from a live Guix System, I didn't need to premount /boot myself; 'guix system reconfigure' took care of it :-) <nckx>mitchell: Our elogind (logind ‘extracted’ from systemd) package uses it to manage user sessions. <mitchell>nckx: oh i see. I thought perhaps there was tighter integration between systemd and shepherd than I initially imagined. <nckx>It is not related to the Shepherd at all. <nikola`>Did someone really get through all of that for a meme <nckx>The only April fools I actually appreciate. There was another high-effort one another year but I'm afraid I forgot what. <nckx>I… really don't remember, sorry. <rekado>Guix System on Hurd started out as an April fools joke. <mitchell>thats very impressive. I know its a joke but it may be useful if for some reason you wanted to use guix to spawn foreign distrobutions due to some hypothetical IT requirements including non-free software blobs <nckx>Not the type I had in mind, but also better than the average ‘[ANNOUNCE] Guix is switching to NPM.js lol *giggle*’ mail/post. <nckx>Seen in other projects, I mean. Not alluding to a Guix one here. <mitchell>I tried one(1) time to package an java script application. Never again lol. Webdevelopment is an absolute s*** show <nckx>There *was* a JS one but it was equally real. <nckx>Come to think of it, that might not even have been a joke. ***mark_ is now known as mjw
<rekado>does anyone know of a suitable MTA for developing a system similar to debbugs? <johnjaye>how does debbugs work? i've never thought about it <rekado>I’d like to keep as little of the ‘business logic’ in the MTA configuration; it really just needs to deal with incoming email from the outside and deliver all emails to a maildir. <rekado>johnjaye: no, it’s written in perl <nckx>I'm insanely biased towards opensmtpd, but I think delivery to maildir is included for free in any common MTA. <rekado>I want to extend mumi to cover a little more of what debbugs already does, weaning ourselves off the debbugs-processed spool directory that we’re syncing from gnu servers. <rekado>nckx: I’ve been reading opensmtpd docs, and they seemed the most accessible to me. <rekado>(we have a wip-postfix branch, which seems to have been last touched in 2020) <lilyp>where is mozjs17-aarch64-support.patch and why is it not on c-u? <nckx>It's not mine but I see a copy in my {d,m,cr}ustry c-u worktree. <nckx>Now it's gone. 5e25a69e6e3733ad8845d1b187940877deba7750 removed it. <apteryx>lilyp: what do you mean by "it's still referenced" <apteryx>'git grep mozjs17-aarch64-support' turns nothing here <nckx>gnu/packages/gnuzilla.scm: (patches (search-patches "mozjs17-aarch64-support.patch")) <nckx>On 0d09e2e29d1ef0afabebd843f51d41d6cfe340ee <nckx>Please be understanding of those. <davidl>So I had a substitute* in package Im working where the replacement string was this: <davidl>(string-append "export BCUPYTHONVERSION=" <davidl>it did not add a newline at the end - probably bcs of the gexp. Is this a bug? <nckx>Why would it add a newline? <nckx>PotentialUser-19: Funny, all newer ISOs I can find exceed the file size limit and hence are guaranteed virus-free. Problem solved. <davidl>bcs all the others do, like this one: <davidl> (("export BCUPYDAEMON=(pydaemon.sh)" _ library) <davidl> (string-append "export BCUPYDAEMON=" #$(this-package-input "pydaemon") "/bin/" library)) <nckx>The ‘3 line’ is like a maximum, maybe once in a while if you can't avoid it type of guideline. <davidl>without adding a newline it will merge 2 lines, which normal substitute* calls doesn't do. <nckx>davidl: It should never add a newline. <nckx>davidl: Your second example isn't matching the newline. It remains in the file untouched. It's not added. <davidl>then I guess the problem is that ("export BCUPYTHON=python(.*)$") consumes a newline (this part: (.*)) <nckx>Your first (incomplete, so we can't say) example might be matching the newline, and you're not giving an explicit newline to replace it. <nckx>.* matches the final newline. <nckx>-> .*$ matches the final newline. <nckx>PotentialUser-19: Yes, and any other Guix-generated ISO I have lying around. <nckx>Drilling into the ‘details’ tab was also a waste of time. No file had that match. <nckx>But really: virus scanners are a racket to begin with, and ‘ExeHeader’ (completely undocumented, another red flag) sounds terribly like ‘oh dear, something is executable, call the cyberpolice’. Maybe it's not, but we can't know, since it's all secret sauce & mirrors to scare you into buying a… oh dear. I'll stop. <PotentialUser-19>i was considering getting one of those, but there is no way to verify them without already having guix set up, bc there are no pgp signatures available for the development builds. So i am either stuck with a potential false positive (stable) or an unverified iso (dev) <nckx>What is that positive worth, though. <nckx>Somebody selling antivirus is telling you you have a virus. <PotentialUser-19>i may be a bit overly careful, ik. I was just wondering if this specific detection was a known thing or if it is unusual for this version of guix system <unmatched-paren>nckx: correction: "Somebody selling a virus is telling you you have a virus." *nckx hands over the cynic's crown, it is yours now, wear it well. <PotentialUser-19>if u would provide a signature with that crown, i would trust it a bit more <nckx>PotentialUser-19: You're the first to mention this Web site in this channel since logs began in 2013 :) <unmatched-paren>PotentialUser-19: no, we need to have a full third-party audit of that crown <nckx>I can't really say more than that. <nckx>I don't intend to be cynical, but that website is saying ‘ooh spooky virus found’, somewhere in a ~650 MiB ISO, and keeping the trivial to share information about *which* pattern matched (a codename with no useful search hits doesn't count) which tiny part of that huge ISO secret behind at least an account wall (I didn't check if it was a paywall). <nckx>You'll colour me the darkest shade of severely unimpressed if I don't mind. <unmatched-paren>it's like the VPNs that show you your location on their websites. because that's a thing now. <nckx>I'm trivial to nerd snipe but not when the counterparty seems so lazily malicious (I mean the site of course, not you :) <unmatched-paren>people become aware of global warming -> companies start making money off it. people become aware of digital privacy and security -> companies start profiting off it. <nckx>PotentialUser-19: Would you know where I could find more information about the report without creating an account? <unmatched-paren>ok, i've found that the gold in the cynic's crown is actually vulnerable to spectre O_o *nckx could continue pointing out details like the ‘static ML’ database, the field of ML being known for its high standards, substance, and proven track record, but I actually want to stop moaning and be constructive. <nckx>unmatched-paren: …I'd actually like to have the crown back if you don't mind. Maybe in a year or so. <unmatched-paren>nckx: sure, you can have it now. -please don't search for 'crown' on cve.org- *nckx is building a ‘bare-bones’ guix system image to throw at the Web site. <nckx>I might have done than anyway. <nckx>It's broken ‘guix lint’ before. <nckx>PotentialUser-19: Sorry for the delay. It took much longer to build than I expected, but I submitted a 481-MiB ‘guix system image -t iso9660 gnu/system/examples/bare-bones.tmpl’ to virustotal.com (which also took minutes) and… same result. So the malware isn't the evil Guix installer that allows you to freely install software not approved & signed by your laptop vendor, which is obviously a security risk and should be illegal. <nckx>I'm a little disappointed I admit. <nckx>I can't reproduce it with any other libre ISO I can think of. <unmatched-paren>It means 'virus scanner' in that it alerts you if you give it something that isn't a virus. <StonedBuddha>I am trying to cross-compile sbcl for armhf-linux. However the 'replace-asdf phase fails because the symbol look up for "cl-asdf" returns #f. It works when building natively. ECL also fails in the same way <johnjaye>um. why does guix system build report "collision encountered"? <johnjaye>we aleady went over this. i have to do guix system build /etc/config.scm first to force it to complete <unmatched-paren>johnjaye: right, ok. i thought it might not be taking so long now that you've done it once <johnjaye>well next time i will redirect out put to stdout <nckx>Two packages probably provide the same file name (say, /bin/ls), Guix picks one at random. <johnjaye>oh ok. i thought it meant something else <johnjaye>ok. it's very hard to tell what is "normal" and what isn't. XD <johnjaye>and yes it is much faster now with the repeated system build command <nckx>They are normal & harmless. Agreed it's not *ideal* that it's shown to users but it's not the highest of priorities to hide or work around it either. <unmatched-paren>well, it has to choose one of them to link to /run/current-system/profile/share/mime/types <johnjaye>hrm. speaking of which. i thought if i did 'guix system build /etc/config.scm' it should do most of the work correct? so after that sudo guix system reconfigure ... should just reboot quickly? <nckx>It won't reboot for you. But yes, it should build fast. <johnjaye>that's bad... isn't llvm downloading the start of the whole process? <nckx>The process of building something with LLVM, generally. <johnjaye>oh. on bsd llvm is used for everything and when you build world that's the first thing it builds <nckx>My first guess was inkscape (for the GRUB background, yes, huzzah for building things from source) but there's no inkscape → llvm path. <nckx>Oh! There is, for llvm@12. <nckx>That'll be it. Oh jeezies: inkscape@1.1.1 → gtk+@3.24.30 → colord-minimal@1.4.5 → polkit@0.120 → mozjs@78.15.0 → rust@1.57.0 → llvm@12.0.1 <nckx>That's really a bit silly. <nckx>To show ‘Guix’ at the boot menu :-/ <johnjaye>the things you learn when building software from scratch <nckx>Not my area of expertise but common sense would beg for it. <johnjaye>unmatched-paren: i can't tell if you're kidding or not <johnjaye>inkscape is for making graphics. that's kind of its thing <unmatched-paren>tbss[m]1: well, there's its usage of scheme instead of the nix language <johnjaye>once upon a time I also typed Why carelessly without checking if I had hit the 'E' button <lilyp>nckx: I do try to be understanding. I don't consider myself an expert on core-updates but I need to build an experiment on it <lilyp>Nix has a configuration language which is Turing complete and also a mess. <lilyp>Denxi has three configuration languages, two of them Turing complete. <unmatched-paren>lilyp: oh, i thought turing incompleteness was one of nix's main goals <lilyp>Guix has one language, which can spawn as many configuration languages as you want. <tbss[m]1>unmatched-paren: What is this abstractions? <johnjaye>nix is supposed to be below turing complete <mitchell>lisp has better tooling and libraries that nix cannot have <unmatched-paren>well, seems like imagemagick provides an SVG converter, but apparently it's terrible <lilyp>you need to be turing-complete if you want to be a meta build system <nckx>unmatched-paren: Terrybl how? If it's just picky, we have complete control over the input, we could tweak it to IMs demands, within reason. *unmatched-paren gonna try it <johnjaye>unmatched-paren: to be clear is this a skin in the game discussion? as in, guix uses svg conversion and it would simplify dependencies to have it? <unmatched-paren>johnjaye: guix uses svg convertion to turn the GRUB background into a PNG <mitchell>tbss[m1]: the operating-system abstraction lets us work with the concept of an "operating system" as a data-type in a general purpose language <johnjaye>i don't understand what you mean. grub only takes png? <unmatched-paren>johnjaye: well, i don't think it takes svg at least. might not be png, but seems the most likely <lilyp>to be fair, some nixpkgs are basically "write a shell script and then invoke it" <lilyp>depends, if you are deep into systemd you might miss some features <mitchell>tbss[m]1: it is once you understand scheme <johnjaye>also is this more of a reproducibility thing? as in, you want to always generate the grub image from the svg instead of having a static png? <nckx>I wasn't joking about building things from source. <johnjaye>even source code of images? as in svg being the source code for pngs? <nckx>But really, a full Rust bootstrap is an unreasonable price for this one. <nckx>The same principles apply. <unmatched-paren>johnjaye: Guix builds the whole system from a smallish scheme interpreter and a smallish c compiler in that smallish scheme <lilyp>we do have an exception for fonts currently which is not nice <mitchell>I'm sure someone could write a scheme svg manipulator <nckx>Yeah if you think SVG conversion is a bit zealous, wait until you read about Mes :) <mitchell>that 120MB bootstrap won't reduce itself <lilyp>i think we should build some fonts from source <nckx>mitchell: Or rewrite the logo in something like the Guile Picture Language, although I don't know if it has the ‘features’ we'd like. <mitchell>how many features do we need for such a simple thing? <nckx>Like the checkered background that I am 97% sure is a bug but enough people actually like that it was never fixed. <unmatched-paren>(i'm not being hyperbolic here; there actually is a hex assembler that we intend to use to build the whole system) <unmatched-paren>"It bootstraps all these from a single 357 byte seed (which you will find in the folder bootstrap-seeds). The ultimate goal is for this to bootstrap all the way up to GCC. Thanks to the wonderful people on #bootstrappable and their hard work https://github.com/fosslinux/live-bootstrap it is done. Everything you need to go from Hex0 to GCC+Guile is just a kaem.run away. <nckx>mitchell: Not many, but I didn't check if things like gradients (as used in the Guix logo) are equivalent, etc. <johnjaye>guix is an interesting project. i've been in other channels before and asked about what are some good project ideas <johnjaye>here people just tell them to you for free! <unmatched-paren>there's also now a kernel written in hex that calls into x86 bios, which can be used to replace linux <nckx>lilyp: Not sure if joke, but yes, we should. <unmatched-paren>so, all you need to build a complete linux system is a few kilobytes of binary code and a BIOS <johnjaye>> Even more recently (2018), the GNU C Library glibc-2.28 adds Python as a build requirement <nckx>nikola_: It's being worked on now. It's not hypothetical. <mitchell>Then we will need to print it off into a book. Then all you'll need is a human and some sand <nikola_>Why is python necessary for glibc though <johnjaye>unmatched-paren: is there really much to be gained by reducing the starting surface to a few kilobytes? <johnjaye>like i understand attack surface and all that but <johnjaye>ultimately you are still downloading code and compiling it <unmatched-paren>johnjaye: well, there's still the BIOS, which is completely unauditable on most machines. there's still a lot of work to do. but yes, it effectively at this point makes supply chain attacks implausible <nckx>It's worth it to enough people willing to dedicate a good chunk of their lives to it. <nikola_>unmatched-paren: Was that really necessary though <nckx>It will always not be worth it to someone. <johnjaye>hrm. i guess the counter argument to that is, if you download it it can be harmful right <johnjaye>or like. to take that article example. the latest version of sed could have a virus in it <mitchell>johnjaye: and that gets propagated through the whole dependency graph. Guix will know if anything changes <nckx>But not every hash is the result of an extensive audit (maybe some day :) <mitchell>nckx: it is true, we are implicitly trusting many projects <johnjaye>even if you pin a certain package version it's still a security thing. which is why i was thinking kilobytes vs megabytes seems a bit tiny of a change <johnjaye>in general i like the idea of reducing deps though like the rust thingie <johnjaye>that was big difference in 1993 sure. but now it's non-existent given we have terabyte drives <mitchell>johnjaye: for the bootstrap seed it doesn't matter that much the security holes. As long as it builds correctly it can build the up to date versions <nckx>johnjaye: What does drive size have to do with it? <johnjaye>i mean. it's linux distros that trained me to not mind downloading hundreds of megabytes of garbage just to install emacs to begin with <johnjaye>ok well if you mean manually auditing that's different <mitchell>johnjaye: you have to establish the trust root somewhere <nckx>Fundamentally, there's no argument against ‘why should I care’ because it's not… an argument to begin with? <johnjaye>but then i fallback on the other position of, you're still downloading code from the internet and trusting it <mitchell>johnjaye: In guix the store hashes are proof of where that binary came from back to the bootstrap <johnjaye>sure. but i don't see the security argument at all. bootstrap big or small, you still have to trust that sed package <nckx>johnjaye: You can actually read & understand the code in a weekend. You cannot, fundamentally cannot, do that with a 150 megabyte ‘bootstrap’ toolchain. <nckx>johnjaye: No, you don't. <nckx>That's where your argument falls apart. <nckx>I mean: ‘I don't see it’ isn't an argument, just a fact about you. It's not something we can discuss, fundamentally. You're right! <mitchell>We only trust that the source code with that hash compiled with these inputs yields a suitably bug-free sed program that we can use to build other things <johnjaye>nckx: ok. but i can't read your mind. so the only way to understand your idea is if you tell me <nckx>Sure. It's a two-way street though. <johnjaye>i know. i'm waiting for you to finish your thought <johnjaye>you just said "your argument falls apart" then stopped <nckx>I didn't have one pending. <mitchell>but unless we can trust the inputs and have a way of tracking them we can't trust anything. Thats the problem with other package managers is they do not offer any guarentees about the binary blobs you are receiving other than they are the blobs the maintainers ment to give you. But you cannot independently audit that. <nckx>Oh, I was just reacting to your ‘you still have to trust that sed package’. You don't, unless you can't read code & don't want to (which is your right! but also a self-fulfilling prophecy that says nothing about sed). <johnjaye>if trust is what you want. and A depends on B depends on C. don't you have to trust A,B, and C? <johnjaye>granted you're giving A more weight than B and B than C <mitchell>C has the most weight because C can propagate malware up the dependency graph <mitchell>If you have the source code for A and B then you can audit them. But you can't audit C in the same way, its too difficult <johnjaye>mitchell: ah ok. so like being able to audit the packages you're installing. that makes sense <nckx>And it doesn't matter that C is a black box, and efforts to make it a documented transparent box are wasted? <mitchell>C carries all the trust and the rest of the packages inherit that trust <nckx>Which is what's happening here: replacing 100s of megabytes of machine-optimised machine code with fewer, ideally kilobytes, human-generated sortacode that can be run by the previous step. <mitchell>the Ideal bootstrap would be a machine code hex file small enough that a human can make sense of it <johnjaye>ok. i guess what i dont' get is if you make C super duper optimized, a few kilobytes, that's great <johnjaye>but if A,B, etc are all megabytes isn't that still trust problems? <nckx>johnjaye: Hmm, why would you do that (optimise C to make it a few KiB)? <nckx>Wouldn't that C be unreadable? <johnjaye>unmathced said 4Kib was absolutely doable <nckx>They weren't talking about compressing the very same binary just to make it look small. <mitchell>you couldn't compile c code with 4kib. We can barely move hex around for that. That builds the scheme interpreter which builds the simple c compiler writen in scheme which can compile a simple c compiler writen in c and so on <nckx>They were talking about a programme (not blob) that does so much less that it's naturally an order of magnitude smaller. <nckx>johnjaye: The point of the project is to remove build artefacts (=binaries you get from a third party, doesn't matter if you trust them) from your bootstrap altogether. So you never run anything that (1) wasn't written by humans and can be read by you, as source code or (2) generated on your machine from that source code. Now, because you're starting almost from scratch, the very first parts of code will be arcane, looking very much like machine code, but that <nckx>part will be *tiny*, a few KiB, and not optimised at all, so it's as easy to understand as possible. That will then build a slightly better something from source code that is a bit more readable. After a few steps you have a rudimentary C compiler that you trust because you [could have] read everything that made it, and then you can audit the next step at the speed of reading C, not assembly. See the goal? It's not about shaving off 100 MiB from a 300 MiB binary <nckx>blob C compiler. Nobody can audit 200 MiB of machine-generated machine code at home. <nckx>Or 100 or whatever it previously was. <bjc>evaluating machine code is solving the halting problem <bjc>a few hundred bytes makes that pretty tough to do <nckx>Even my ‘looking very much like machine code’ is not to be confused with ‘actual machine code’. It's wearing lipstick & everything. It does things slowly, so you can watch its hands. <nckx>^ hey there good lookin' <nckx>johnjaye: I have two modes: too short & too long. Apologies for going full mode 2 on you. I hope it remotely made some sense. <luishgh>hi guix, i wanted to know your opinions on nix flakes. do you think something similar could be added to guix in the future? the rfc [0] mentions the motives for its inception and it seems some of them (the second and third) also apply to guix today. <unmatched-paren>luishgh: seems like the 3rd is solved by channels? not actually sure what it means <unmatched-paren>the second is not an issue, as i think the names guix.scm and manifest.scm are actually standard and baked into guix <luishgh>i think the main issue stil remaining is dependency management <luishgh>currently you need to add revision details manually <luishgh>instead of it just generating those into a lock <unmatched-paren>i never found updating those to be particularly challenging myself... <nckx>Is there a ‘Nix flakes for non- (or ex-) Nix users’ explanation for folks like me? The scant documentation I've read so far assumes you already intuit what they are. <luishgh>unmatched-paren: i think it adds a maybe unnecessary barrier to inserting unpackaged dependencies to projects <luishgh>maybe not exactly something as complicated as flakes, but a subcommand for generating and managing those interactively could provide value <nckx>So far they look like a mashup between channels and manifests, but that's an awfully Guix-centric view. <luishgh>nckx: the link i sent was the best resource on it i could find <bjc>what does "nix project" mean in this context? is that the closure of a nix configuration definition? <nckx>I read it as projects using Nix for development and esp. deployment, not a Nix-internal thing. Just English. <nckx>Like C projects with a guix.scm in their git repository (one can dream). <luishgh>nckx: me too. like a python project where you use nix/guix instead of virtualenv or something similar for dependencies <unmatched-paren>nckx: Well... i'm doing a few C projects at the moment. So soon that dream will be a reality i guess :P but probably not with very good code <nckx>Yes, they use Nix, I missed a chance :) <nckx>That's upstream, not nixpkgs, code. ***jess is now known as meow
<nckx>Having that magically compose into a NixOS system sounds pretty neat, and that's what I imagine flakes do. Or help do. <nckx>I haven't tried it myself, I use another OS now, you've probably never heard of it. <bjc>so this looks like a way of tracking dependencies for a project outside of coordinated channels <bjc>i'm not entirely sure of the value, but on its face it seems like a good idea to me <nckx>Also a way to bring back dependency bundling back in through the back door if you're not careful. <bjc>right, which is why i'm skeptical <nckx>There was at least one back too many in that sentence. Sorry. <bjc>but channels are kind of heavyweight for a lot of things <nckx>But it would be a step back :-/ <bjc>the more i think about it, the more i think that the benefits i see are actually better solved with channels <bjc>unmatched-paren: it'd be more useful for non-coordinating parties. project a has a flake file, project b can depend on that for its build without any input from a <bjc>it looks a lot like rubygems/cargo/etc <unmatched-paren>that seems... counterproductive. i thought half the purpose of nix was to be secure <bjc>yeah, it's weird. maybe there's something i'm missing <nckx>unmatched-paren: Only in as much that ‘secure’ is understood to be part of ‘good deployment’. The purpose of Nix is to ease deployment. So it's more of an implied design goal. Of course, it does not aim to be insecure. <nckx>Is it just me or am I exceptionally bad at generating human-sounding sentences today. I don't know what's the matter. <nckx>‘You get the gist.’ — there. <johnjaye>scifi shows sometimes did that sincerely. like when tori higgins wanted to quit SGA they made her character into an evil android ***meow is now known as jess
<nckx>I just mean, a lot of Nix decisions make a lot more sense with your 🌈devops! glasses on, it's a very different culture. <nckx>sneek: please not to eat us, here botsnack <nckx>Noooo. We are stringy and tough. <nckx>[unmatched-paren: shut. uuup.] <luishgh`>nckx: yeah, devops seems to be a huge part of the nix community <luishgh>i hate when my connection fails and ERC reconnects using a dummy username <bjc>i must be missing something; if nix is just about deployment, how's it improve on puppet/ansible/etc? <bjc>or is it just another take on the same problem set? <luishgh>i mean, packages in nixpkgs aren't even boostrapped, a lot of them just download binaries, so the goals are definitely different <nckx>I'd say it takes a wider (and hence more well-integrated) approach? I won't answer the actual question, since I'm not familiar enough with Puppet/Ansible, but my understanding was not that they actually deployed services from source. <nckx>I thought they were closer to ‘guix deploy’ than to Nix/Guix in general. <bjc>they don't, no. they take your os' package system and run with it for most things <tricon>i develop and maintain an Ansible deployment for my company and use it in part to deploy Guix servers on our VM infra. <bjc>they can do a ‘guix deploy’ equivalent, and it's their primary use, but they do it by configuring individual machines into a predictable state <bjc>there's a *lot* of overlap with what guix does. but they're not package managers, no <tricon>unmatched-paren: eventually, that'd be nice; and it's something i'm considering long-term; but Ansible has a community package that integrates with our centralized VM manager and provisions and configures things across our hypervisors. <tricon>so eventually i can guix deploy the machines themselves; but the "virtual hardware" is configured by Ansible. <tricon>tbh, as much as i like Ansible, i'd love a "Guile Ansible", the "Guix way" if you will. so much work to build something like that ground-up. <tricon>as it stands, Ansible has packages for managing firewalls, servers, and all sorts of infra. <dmj`>dhall can be kind of annoying too <bjc>for all of puppet's problems, at least its configuration is readable. i wish yaml didn't exist <bjc>i will never understand why so many projects use it <dmj`>kubernetes is death by yaml <dmj`>and once you really learn nix / lisp you won't see the need for another level of abstraction, like dhall <bjc>everything yaml touches is death by yaml <bjc>iirc yaml is a superset of json <bjc>which, inexplicably, wasn't enough, so they had to cram a completely separate, uglier, and more error prone syntax on top of it <drakonis>it is pretty much an attempt to make a better nix lang for configurations <tricon>with YAML, you end up quoting more stuff than you need to, "just in case", which decreases readability. i think that's even recommended in the YAML docs: "just quote your values". then you fudge with spacing on output due to the intesection of literal spaces and significant whitespace. <drakonis>it also has direct haskell interop iirc? <tricon>i'm pretty over significant whitespace syntax. <tricon>(recommended in the Ansible docs.) <sleepydog>i have been using guix to manage dependencies for my ocaml projects. i keep a guix.scm at the project root. so far it is working well, i'm fixing problems as i see them. i'm trying to keep guix optional for contributors, for now <sleepydog>i want to try using guix for larger scale tests of the projects, similar to guix's own whole-system tests. but that's still WIP <unmatched-paren>it looks like significant whitespace due to how it's usually formatted, but it isn't <sleepydog>yea, i've grown fond of the syntax, even though some people are put off by anything that doesn't look like C <luishgh>sleepydog: could you share a link to them (if they're public of course)? <sleepydog>i hit one issue in the ocaml-ctypes package and two issues in the ocaml build tool (dune). I fixed #1 and there are PRs to fix #2 in progress <sleepydog>i just run `guix shell -D` and then follow a normal ocaml work flow (dune build, dune test, dune exec, etc) from the new shell <luishgh>thanks unmatched-paren nckx and bjc, i think i'll develop a guix subcommand to easily update and then lock the channels.scm of a project. then i think i'll have a good workflown <nckx>Yeah, I think the building blocks are mostly there. <nckx>Best of luck, let us know how it goes! <sleepydog>what do people think of adding the `--with-*` transformation flags to `guix shell`? For example I wanted to do `guix shell -D --with-source=dune=path/to/modified/dune` a few times and I think it would be useful for "quick & dirty" modifications of dependencies <nckx>sleepydog: …I think that's just a bug? <nckx>You mean it didn't work? <luishgh>nckx: i have actually done a subpar clone of niv as a guix subcommand (is doesn't work and i don't actually plan to maintain it, it was more of a learning experiment) so i only need to discover how i would get the latest revision of a channel <sleepydog>nckx: i thought it didn't work, let me check <nckx>Yes, I just found out oneko is in Guix, I'm over multiple moons. <nckx>Alas it works not on Wayland. <nckx>luishgh: A Web search for ‘niv’ gives me only highly irrelevant results. What is it? <nckx>sleepydog: It's such a good idea that it's already there, so you've got that going for you. <sleepydog>nckx: huh, it seems to work. i don't know how i got it in my head that id didn't. thanks! <luishgh>i'll say current documentation on extending guix is definitely subpar, i only got thins going by reading guix gwl and home source code <luishgh>nckx: basically it was the easy way of pinning nix channels when flakes weren't around <nckx>I think that postdates my Nixness. <nckx>Or, equally plausible, I'm so uninterested in ‘pinning’ that it never came up. <luishgh>yeah, unless you do project management with nix it isn't very useful <luishgh>btw, have any of you messed with the xdg home-services? <rekado>luishgh: the extensions stuff was motivated by the GWL <luishgh>rekado: really? that's cool, and it makes sense as i think ludo is involved with it <rekado>I didn’t bother documenting it much, because we hadn’t formed consensus on whether the approach was actually good. <rekado>we’ve had a long time of … installation problems with the GWL, where it really wasn’t clear at all how it should best be installed <rekado>as a package? A channel? Something else? <rekado>what version of Guix would it effectively use? The old version of the ‘guix’ package you’d get if you ran ‘guix install guix’ (don’t do that), or the same Guix that ‘guix describe’ declares to be? <luishgh>rekado: what would be a good folder structure for a guix subcommand as a channel? for extensions there is guix/extensions, but for channels i haven't found something similar <rekado>adding support for GUIX_EXTENSIONS_PATH was just a tiny piece in the puzzle <rekado>luishgh: I really don’t know. This is all pretty new. <rekado>I guess we just have to make things up as we go and learn from our mistakes <luishgh>rekado: makes sense, guix isn't that old itself after all lol <sleepydog>does it *need* to be a guix subcommand? why not just build a standalone script and if everyone likes it, send a patch to add it to guix <luishgh>rekado: 10 years can be a lot and not much depending on how you see it <luishgh>i just think a subcommand makes it more clear that it depends on guix and also makes it "seem more integrated"(?) i haven't give much thought to it <drakonis>also integration is always good, in a manner of speaking <luishgh>drakonis: yep, that's a major benefit <luishgh>if it's done as a subcommand, it is really straightforward to upstream it latter on <drakonis>nix has a very large amount of third party tools that aren't directly maintained <johnjaye>is GWL supposed to be like jupyter or mathematica notebooks? <drakonis>it gives nix this air of being cobbled together <rekado>johnjaye: GWL is a a DSL to declare scientific workflows — with deployment built in. <rekado>notebooks are meant to be much more interactive and interative <sleepydog>luishgh: what i mean is, if your feature is really great, it should go into guix proper. but if you're still trying things out and don't know how it should work yet, make it standalone to get feedback <sleepydog>i think it's a useful property that everyone running the same version of guix has the same subcommands and options available <rekado>sleepydog: on the other hand, it’s almost trivial to make it an extension. And the extension can just use Guile modules from Guix. <luishgh>sleepydog: i mean, there are a lot of channel management scripts already out there <sleepydog>rekado: i'm not familiar with the types of extensions you're talking about. do you have an example? <luishgh>sleepydog: basically you can define new subcommands for guix with the `define-command' procedure <rekado>it provides a ‘guix workflow’ command. <rekado>and ‘guix help’ lists it along with a description <sleepydog>ah, i didn't realize it showed up as a guix subcommand <sleepydog>luishgh, rekado: thank you for sharing, it looks easier than i thought <rekado>it doesn’t do *much*, but the mechanism exist to signalize some kind of unity and communicate expectations <luishgh>rekado: yep, i think having something like that is much better than how nix manages tooling around it, with everyone using different languages and user interfaces. <nckx>Does Nix proper still use Perl? <nckx>I was actually going to say ‘…maybe by now they upgraded to Perl 6’ but decided the better of it. <drakonis>nix proper does not have a perl dependency but nixos still does *unmatched-paren writes petition to rewrite nix in the one true text language, awk <nckx>Adjacent: It had been so long since I'd read Nix code, that today it finally clicked: I saw some and it just looked… Well, horrible. I guess I'm cured? Not sure what to think of it. It was a genuinely strange feeling. I'd always been quite comfortable with Nix, noticably so compared to others. <nckx>drakonis: Wow. That's some core stuff, too. <civodul>nckx: heheh, i know that feeling :-) <nckx>Stockholm is a beautiful city but I don't think I'll be back. <nckx>unmatched-paren: Sure, but that's to build CL packages. <nckx>unmatched-paren: Whilst the .pl stuff above is actually core stuff, what we'd call activation snippets. <drakonis>c and python is used in the test harness <drakonis>plus a sizeable amount of update scripts <nckx>Test harnesses are generally weird though, Guix is an outlier in its consistency there. <nckx>In other places, if a project isn't submoduling 3 random copies googletests it's already ahead. <lilyp>you got a project that submodules only googletest? <lilyp>amateurs, don't they know that you have to submodule zlib and make it so that it doesn't actually build? <drakonis>C is also used for straight up replacing bits of code <drakonis>although i'm not sure why the heck is it that they're using it for tests <nckx>lilyp: Reminds me of mozlz4, but sadly, that builds. <unmatched-paren>also, this is a meson project, and it's written in rust so cargo is required. <nckx>The inner loops are written in assembly, but it's wrapped in Rust so it's safe. <nckx>At least the compiled version of valgrind in the git repo that nobody can quite reproduce says so. <bjc>now now, that's just mean. at least rust makes you mark it ‘unsafe’ so you can go audit it as soon as you're done with the rest of your tech debt <lilyp>Don't worry, the borrow checker will take care of that. <nckx>It produces no warnings before segfaulting. <unmatched-paren>plus multiple DLL blobs are included, and the build fails if you delete them, even if you aren't on windows. <nckx>Right, so, there *has* to be a worst-practices.git joke repo… <bjc>the sad thing is i actually /like/ rust. well, not the language, which is pretty bad, but the borrow checker. unfortunately, rust is the only language i know of that has one of those <lilyp>Worst practice #1: Be OpenModelica. <johnjaye>bjc: the answer is to do what rust does but do it better! <nckx>I'm finding a lot of snippet collections maintained as git repos, but no one ‘‘‘coherent’’’ hellscape codebase yet. <bjc>it's not fractal enough in its horrors, but it's good <nckx>A slightly more corporate flavour of hell than I'm used to, but still a worthy effort. <bjc>i have worked on some truly hellish code, but it, unfortunately, cannot be shared <bjc>but i will share one gem: we had a classes called FooServerServer and FooServerClient <bjc>this project used c++, but we weren't allowed to use any features except templates <lilyp>Well obviously you need to distignuish FooServerServer and FooDaemonServer <lilyp>bjc that's actually good then <bjc>and, the icing on the cake: we all had to use the same emacs config, so the project lead could sit at our desks and use our computers <lilyp>C++ template programming is basically functional programming at compile time. <bjc>(three things, i got carried away) <bjc>lilyp: i'm laughing. should i be laughing? <lilyp>I mean it's a factoid shared among C++ experts, so it's supposedly true? <nckx>bjc: The implication that you had to use straight qwerty for the same reason is what really makes me wince. <bjc>nckx: i blatantly disobeyed the emacs thing. and my layout was dvorak. i have limits <nckx>bjc: It's fine, the off-by-one error was perfectly fitting. <bjc>my favorite thing about using a non-standard layout was when people would take your keyboard to type, hit a few letters, and hand the keyboard back in disgust <lilyp>I don't get the Dvorak thing tbh, but for Emacs, they do know that they could just put their init.el on a flash drive and then start Emacs from the command line pointing it towards their config? <bjc>literally anything is better than qwerty, and i've been using dvorak for a long time <bjc>though i'm thinking of picking up workman, just to feel that sensation of confused fingers again <nckx>lilyp: Something about the phrase ‘C++ expert’ makes me think of somebody who shouldn't be considered an expert in anything. <nckx>bjc: <my favourite thing> This. <bjc>c++ has come a long way over the years, in all honesty. it's much better than it used to be <nckx>Works wonders with the illjustborrowers. <bjc>it's still the "nailing 4 legs on a dog to make an octopus" thing at its heart, but the octopus can at least squirt ink now <lilyp>I do mean the big names in the C++ community though, like Jason Turner, who often talks about templates and how some of those can be done away with now that lambdas, constexpr and (as of C++20) concepts exist. <bjc>constexpr is great. as an idea. as an implementation it's extremely c++ <lilyp>I do perhaps watch an unhealthy amount of C++ related videos. <nckx>I'll admit that my limited C++ experiences firmly predates lambdas. But I feel somewhat entitled to imagine the C++ version of a λ and that it would make me scream somehow. <bjc>it's nice that there are legitimate and powerful ways to finally get rid of so many #define macros *rekado also types dvorak and uses emacs; remapped C-t to C-x because of the awkward placement of x. <lilyp>What's wrong about [&x](auto z) -> decltype(z) { return z + x;} <rekado>(for confused fingers I use different keyboards once in a while.) <nckx>rekado: …you like awkward? <lilyp>meh, should have captured x by value rather than by reference *nckx also uses Dvorak, frantically moving fingers around trying to figure out what rekado means. <nckx>This some kind of palm thing? I can't do those on my laptop. <rekado>nckx: when I mean to do ‘C-x’ I hit Ctrl with my left hand and hit ‘t’ with the middle finger on the right hand. <rekado>it’s actually ‘C-t’ but I told Emacs that this means ‘C-x’ <bjc>do you not have the control key in a reasonable place? <lilyp>C-x is quite close on qwerty <bjc>and it's still bad to C-x? <bjc>well, to each their own ;) <nckx>rekado: Oh, I see. C-x is nice on this keyboard, with ctrl:swapcaps, but I can see how it could be a stretch. <rekado>I find that an uncomfortable stretch <lilyp>makes sense, but why not take whatever's at qwerty x for dvorak? <nckx>I have that issue with M-x. <bjc>i use the menu key for M-x <rekado>on my now dead thinkpad I used the right mouse button for M-x; lovely thumbkey, that. <bjc>the thumb cluster is mod keys, so they're always easy to hit, and the palm key for a layer switch is a revalation <bjc>i don't have need of a keyboard that small, or i probably would have gone for one <nckx>Bu then how to right-click? <rekado>nckx: I used it only in Emacs where I never needed a right click. <rekado>mouse-3 is bound to a few helpful things in Emacs, but I only ever triggered them by accident <nckx>I didn't even manage to link to the right keyboard, I figured out too late. *nckx goes down into the .emacs mines, let's do this. <rekado>I could have misremembered; maybe it was the middle mouse button. One of them felt nicer, so I picked that one. <rekado>bjc: my problem with that keyboard — and actually *any* external keyboard — is desk space. It’s also inconvenient to set everything up when using a laptop in different places. <nckx>This is an X220 keyboard, I think they're similar. 
