<grasshopprWhoppr>does it even matter in this system since this system is designed to easily switch between several versions of a package?
<mark_weaver>I don't see how that relates to the fact that it's useful to see if any processes are still running with some old (possible vulnerable) code.
<mark_weaver>I think there's space for thinking about how to support that more nicely in Guix, although I'm not sure what it would look like yet.
<jgrant>I don't get the point of such a thing... is there any tangible advantage I can't see?
<mark_weaver>I don't know what you can see, but e.g. if I patch a security vulnerability in some library on a production server, I'd like to ensure that no executables are still running that contain the vulnerable code.
<grasshopprWhoppr>oh yeah, mark_weaver, we wouldn't want to run vulnerable code in that case
<jgrant>(package-respawn-when-upgraded) or whatever.
<mark_weaver>it's probably not hard, it's just a matter of deciding on exactly what it should do
<mark_weaver>I mean it's probably not hard to provide a listing of processes that are still using some old code. respawning is another matter entirely.
<jgrant>I do very much like that while Guix is move of a spiritual offspring in the longrun (obviously we are a physical one now via Nix's deamon but all plans I've heard is regarding making it Guile all the way down), that we can till take and exchange ideas with the Nix(OS) community,
<mark_weaver>it's not immediately clear to me how to do that automatically.
<grasshopprWhoppr>opensuse's zypper does that: lets you know when processes are still using old files and what zypper command will list the processes
<davexunit>guix could list processes running the old software and no take any further action.
<jgrant>What, like "guix proc --outdated"? So it'd just print all the process in a terminal?
<jgrant>That't kinda be cool if Guix could display currently running processes and even knew what was outdated ... even, as davexunit suggested, action isn't taken on such things (at least by default).
<jgrant>"guix running" might be a better name for this, actually instead of "proc" as I gave a weak example for... since we have a /proc.
<jgrant>Straying from this topic though, how would one handle something like bootstrapping from a binary in Guix?
<jgrant>I want to have my hand at SBCL, but it depends on an existing CL implementation and I don't really trust GCL for this job.
<mark_weaver>if you have reason to believe that a gcl-compiled sbcl has problems, then the next best thing is to do what gcc does by default: first, gcc is compiled with the original host compiler, then that "first stage" gcc is used to compile gcc again. it actually goes on to compile a third one from the second and make sure the last two outputs match.
<jgrant>mark_weaver: Do you think it's worth working on Clisp instead? For my purposes, it doesn't matter much (Stumpwm) -- but Clisp is another GNU Implementation... but SBCL is the most popular CL implementation.
<jgrant>Assuming that I figure out libffcall, that's all the depends I need for Clisp.
<jgrant>DusXMT: Yeah, I'm not saying the steps are crazy or anything -- just that it'd be crazy cool to have a "one step" dev environment set up.
<a_e>And imagine, I just found 30GB on my disk not used by my lvm!
<jgrant>You could practically get rid of ./pre-inst-env in such a system too, where you can just direct guile directly to (use-modules (gnu packages stumpwm)) instead of adding another set, which is nice.
<jgrant>civodul: Hey, I still have those syntatic sugar macros for use-modules of packages, system, and service files... is gnu.scm still the place you want me to throw them?
<a_e>jgrant: Does "guix environment guix" not do what you are looking for?
<jgrant>a_e: Unless I'm misunderstanding said feature, no. I want to basically have a command that will clone into the git repo (of Guix specifically), place it in a directory I want, and I can start working on/in it.
<jgrant>Hm, wouldn't this be more ideal for a "guix devel" type command to use profiles in the capacity you would want to see what is exactly in your divide of the store? :^P
<jgrant>In any case, I'll look into it. Ideally though, I'd want a oneliner to go from a brand new Guixotic system, to a develop environment (specifically for Guix) ... which, to my knowledge (which could be way off) does not exist.
<a_e>While packaging KDE, I am actually packaging GNOME...
<a_e>I need libqtzeitgeist and mixed it up with zeitgeist without libqt.
<davexunit>jgrant: it's not one command, but all you need to do is: git clone <git-url>; guix environment guix;
<jgrant>civodul: Is Guixotic the given name now; I don't want to cause another petty bickering over this -- I just see some places this needs to be changed to suit this. Like in the README "* Installing Guix from Guix".
<jgrant>I'm pretty much over all discussion of such a thing on either side, I am not a fan of the name, but I will respect the name Guixotic until there is significant reason to dismiss it. I am interested in how RMS weighs in though.
<jgrant>civodul: Bugging you one more time about this, is "use-module-packages,services,system" still a good thing to throw in gnu.scm. I know we talked about this now like 2+ months ago ... but I'm finally getting back into Guix devel.
<jgrant>Well, I guess really all software development. Kinda been in a blackhole of productivity for a good 2-3 months there ...
*jgrant has been sitting on that patch, a few for stumpwm, and one trivial for lispkit.
*DusXMT just got shivers, rememberhing how he struggled with getting his patches into git-format... and the worst part, he already forgot how...
<jgrant>It drives me nuts that Scheme-mode doesn't highlight some stuff.
<rekado>DusXMT: don't you use git format-patch to create patches from local commits?
<davexunit>git format-patch -n # where n is the size of your patchset
<DusXMT>rekado: I haven't learnt how to use git yet... I've tried diving in several times, I just always fell over my nose
<rekado>DusXMT: there's https://try.github.io which teaches the basics (and you rarely need more than the basics) in about 15 mins. It's browser-based (meh), but it might be useful for a beginner to get the ideas behind git.