IRC channel logs


back to list of logs

<davexunit>whoa, those monad macros are impressive
<grasshopprWhoppr>Today, I read that NixOS will automatically restart an application after updating a package that it uses. Does Guix do that?
<davexunit>grasshopprWhoppr: no.
<davexunit>I'm curious how that would even work
<davexunit>certainly not a feature I've ever wanted. I need to see what the use-case is.
<grasshopprWhoppr>It's not that important, and it might even backfire with a network service; but I try to see if any packages depend on obscure packages that I upgrade.
<mark_weaver>grasshopprWhoppr: I recommend using 'lsof' to find remaining users of old executables or shared libraries.
<mark_weaver>it's easier to do that trick on Guix (or NixOS) than other systems.
<mark_weaver>on other systems, you have to pay attention to inode numbers in the output, because the old and new versions have the same pathname.
<grasshopprWhoppr>ok, appreciated
<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
<mark_weaver>anyway, 'lsof' does the job for now.
<grasshopprWhoppr>just run on old directory?
<mark_weaver>e.g. lsof /gnu/store/.../lib/
<jgrant>I mean, would this be that hard to implement? Being an idiotic 3rd party in regards to Guix's core design, it doesn't seem to be (at least from a cursory glance).
<jgrant>Just have it toggable in the OS EDSL, :^P
<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.
<jgrant>more of a*
<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>what job don't you trust it for?
<jgrant>mark_weaver: Compiling SBCL.
<jgrant>I'd trust it for Maxima, but that's about it.
<jgrant>I was working on libffcall yesterday (for Clisp) and kinda got frustrated and stopped working on it.
<jgrant>It's been so long since I've written my last package, that I've forgot a lot of the finetune stuff. :^P
<jgrant>That being said, I've been gearing up this patch /finally/ for gnu.scm ... though, I still think it's a bit of an awkward place to throw this.
<mark_weaver>if it's possible to bootstrap sbcl from gcl, then we should do it. starting from a binary from elsewhere should be avoided at all costs.
<mark_weaver>(if there's any viable alternative, I mean)
<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.
<mark_weaver>I would start with clisp, yeah.
<grasshopprWhoppr>quicklisp is the shit, now
<mark_weaver>we should package sbcl at some point, but it's likely to be much more challenging to build from source.
<grasshopprWhoppr>(another stumpwm user)
<jgrant>Well, I'll look back into libffcall more tomorrow. I still have NO idea what was messing up the config, especially since I can't find listed depends for it anywhere.
<mark_weaver>if you paste the build output somewhere, I could take a look
<jgrant>So I couldn't contrast what was in needed for it that wasn't in the gnu-build-system.
<mark_weaver>in general, the thing to do is look in config.log for details on what test program it tried to compile and what error was produced.
<jgrant>mark_weaver: I'll need like 10-15 minutes, I got so frustrated and sleep deprived I deleted my whole devel directory ... :^P
<jgrant>Oh, well thank you Emacs!
<jgrant>I deleted the directory, but didn't kill the buffer!
<mark_weaver>heh :)
<grasshopprWhoppr>oh, forgot—sbcl before quicklisp
<jgrant>Not like it was a huge deal or anything ... it's pretty much just a fill in of Hello's example. :^P
<jgrant>Hm, my paste is too large for
<jgrant>I guess I'll try
<mark_weaver>can you select a relevant excerpt?
<mark_weaver>that site is not friendly to my web browsing setup (tor, cookies and scripts disabled by default, etc)
<mark_weaver>if you want me to look at the error, please just post an excerpt of reasonable size to a site that's more friendly (e.g.
<jgrant>I mean okay, but it shouldn't take you to the site -- it just downloads the file. :^P
<mark_weaver>when I point my web browser to that URL, I first get asked to solve a captcha, and then after doing that it gets stuck, probably because javascript and cookies are disabled.
<mark_weaver>I tried enabling cookies, but that wasn't enough to fix it.
<jgrant>I don't know man, it's just a direct download link for me. :^P
<mark_weaver>that's probably because you're not using tor, and you have cookies and javascript enabled.
<mark_weaver>oh, wget worked. hmm.
<mark_weaver>well, now I'm not sure what happened. maybe my own mistake.
*mark_weaver looks
<mark_weaver>well, I see a problem
<mark_weaver>checking how to recognise dependent libraries... file_magic ELF [0-9][0-9]*-bit [LM]SB (shared object|dynamic lib )
<mark_weaver>or at least I think it's a problem.
<mark_weaver>it probably indicates an ancient libtool was used to bootstrap this source tarball.
<mark_weaver>we'll probably have the patch the relevant bits of configure
<mark_weaver>*have to
<jgrant>Well, that's probably above my skill level then at this moment. :^P
<mark_weaver>I'll take a look
<jgrant>mark_weaver: Well, it'd be much appreciated. :^)
<mark_weaver>it is certainly ancient
<mark_weaver>(this build system)
<mark_weaver>circa 1997
<jgrant>Well, unless I'm looking wrong -- it seems like the last release was in 2005 or-so, generally.
<mark_weaver>could be, I was just talking about the build system
<mark_weaver>and really just a date in a comment at the top, not a reliable data point
<jgrant>mark_weaver: Well yeah, I'm saying it places the toolchain to be ancient if it was from like a decade ago or more.
<mark_weaver>oh, but the libtool is from 2001, but much seems clear
<mark_weaver>I see the problem, yes
<mark_weaver>well, I fixed a problem, but it turned out to be a different problem than was caused that error.
<mark_weaver>I see that Debian is using a newer version of ffcall than the latest tarball release: "cvs20100619"
<mark_weaver>I think the ancient libtool is causing problems
<mark_weaver>the version of ffcall in upstream CVS has a much newer libtool (from 2008)
<jgrant>I mean, we kinda have a thing against using non-canonical stable releases, right? :^P
<mark_weaver>sometimes it's needed :)
<mark_weaver>but it's a pain. especially since they're still using CVS, and we don't yet have a fetch method for CVS.
<jgrant>mark_weaver: I mean, as discussed a bit last night... is there a debian source mirror or something, floating around? :^P
<jgrant>Well, there is but it's seperated into Debian esque packaging standards.
<mark_weaver>adding a CVS get method might not be that hard. I'm looking into it now.
<jgrant>mark_weaver: Okay, cool.
<mark_weaver>(i.e. add something analogous to guix/build/svn.scm for cvs)
<jgrant>Things are never "easy" ... :^P
<jgrant>Gonna try building with one of these.
<mark_weaver>we should nudge the current maintainer of ffcall to make a release
<jgrant>Yeah, that's not at all a bad idea.
<jgrant>Welp, it died in the same place with the newish CVS version ...
<jgrant>Yeah, I'll probably look into a bit more tomorrow.
<jgrant>I'm more somefactor of "concerned" to get my syntactic sugar patch made and reinstalling Guixotic on my dedicated test machine by Tuesday (School starting up again).
<jgrant>So, is wireless more preferable now at all? Like assuming I set up wpa_suppicant, things should be relatively trivial with iw?
<mark_weaver>jgrant: wireless is fine, you just have to run wpa_supplicant manually for now.
<mark_weaver>jgrant: well, I added support for fetching source from CVS, and made the libffcall package use it, but even with the latest from their repo, the same error occurs.
<mark_weaver>so it'll require more investigation, which I'll have to hold off on until later.
*mark_weaver goes afk
<jgrant>mark_weaver: Yeah, np. Ty for all the help thusfar.
<mark_weaver>we'll get it sorted out
<jgrant>mark_weaver: Yeah, I'm hopeful.
<civodul>Hello Guix!
<jxself>Good morning, sir.
*bavier is chasing down dependencies for a hydra package
<civodul>bavier: nice, and a good occasion to take advantage of the cpan importer!
*DusXMT is pretty excited to finally get back to Guix(otic), after being distracted from it for quite some time
<bavier>civodul: yes, the new importer is getting a good workout ;). I've got at least 60 new perl modules packaged.
<jgrant>DusXMT: Developing or running it?
<civodul>bavier: woow, indeed
<civodul>having Hydra will be useful
<civodul>we may be able to run Guix(otic) on the front-end
<civodul>... unless davexunit comes up with a fancy 'guix publish' by then :-)
<DusXMT>jgrant: both, I already have plans on what I could do
<a_e>bavier: Congratulations!
<jgrant>Is the devel experience a bit less painful now, setting everything up in Guixotic?
<jgrant>SSL not having to be disabled, for one.
<DusXMT>Someone packaged a set of CA certs? \\o/
<jgrant>DusXMT: Nah, that's a question. Not sure.
<jgrant>Also, having to manually set paths to stuff like like libgcrypt etc, etc.
<jgrant>Manually fetching dependencies.
<DusXMT>`manually fetching dependencies'? I thinght that's a package manager's entire purpose
<jgrant>Ideally, it'd be cool if we had a "guix devel" module where we could just type "guix devel ~/" and it'd clone guix in whatever directory you specify and maybe make a custom profile for it.
<jgrant>DusXMT: To my knowledge, there's no easy way to "guix package install --build-deps guix" ?
<DusXMT>jgrant: Read the README file, and you're set to go :)
<DusXMT>Of course, such a feature would indeed be neat
<a_e>I ran out of diskspace in / today.
<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.
<civodul>howdy, a_e!
<a_e>jgrant: Indeed, it does not clone. But it should place all build dependencies into the store and switch into a bash where they are available.
<jgrant>So I can have a brand new system of Guixotic, run "guix devel" or whatever, and have a developer environment ready like that.
<a_e>civodul: Quite well. As I wrote, I just found 30GB hidden on my disk ;-)
<civodul>jgrant: 'guix environment' greatly simplifies things, as noted in README/HACKING
<jgrant>a_e: So, they have their own profile?
<a_e>No more problems with packing and unpacking texlive!
<civodul>a_e: pretty cool
<civodul>i dream of that everyday ;-)
<davexunit>jgrant: 'guix environment' doesn't use profiles
*civodul is happy that he found a bug + fix + workaround
<a_e>civodul: Congratulations!
<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".
<civodul>jgrant: i don't know!
<davexunit>jgrant: that section is accurate, because it's installing the package manager, not the distro.
<civodul>a_e: "cute zeitgeist", that's a nice name
<jgrant>davexunit: Ah, sorry, yeah.
<a_e>Right now, I am packaging telepathy-glib, which can use gobject-introspection.
<a_e>So far, the packages I have seen put it as a native-input.
<a_e>Should I do the same?
<jgrant>I guess that isn't exclusively tied to Guixotic.
<davexunit>I mean, I guess it *could* be changed.
<civodul>a_e: depends on whether it uses it for the 'gir-scanner' command or for the library itself
<davexunit>but it's possible to do that from any machine that runs Guix.
<jgrant>davexunit: I would more-so now added a parenthetical classifier. "(This also means setting it, in Guixotic)" or something, somewhere in that section.
<a_e>civodul: Zeitgeist is a strange name. "L'air du temps".
<jgrant>davexunit: Yeah, agreed.
<davexunit>jgrant: the more I think about it, the more I think it should use the distro name, as you suggested. :)
<jgrant>davexunit: I'll respect whatever civodul decides on, but yeah, I really like Geist as a name (still). :^P
<a_e>civodul: I do not see any use of gir-scanner in the logs. So I will use a normal input. Thanks!
<davexunit>jgrant: a new name was pitched: GNU Software Distribution
<davexunit>a lot of us like it.
<davexunit>we're awaiting word from rms about it.
<jgrant>davexunit: Yeah, I don't think RMS will every go with that though.
<a_e>Ah, no more name discussions, please! It is getting quite tiresome.
<a_e>Agreed with jgrant, nevertheless.
<davexunit>agreed :)
<jgrant>a_e: Yeah, that's why I put the disclaimer that I personally don't really care eitherway. :^P
<davexunit>he might. we'll see.
<civodul>davexunit: rms kindly offered to go find another name:
<a_e>What's in a name?
<a_e>That what we call Guix, by any other name would feel as sweet.
<davexunit>civodul: sigh.
<davexunit>whatever. guixotic it is.
<davexunit>that we call Guix, by any other name would have as many parens
<jgrant>I've played around with marketing for Geist, namely branding and got if anyone happens to be interested. :^P
<jgrant>Basically the G is a eval-apply sign a'la SICP.
<davexunit>I'm gonna go write code before I get too angry.
<jgrant>I don't know, I really like the name. I'm completely fine if Guix doesn't use it -- I'll just end up recycling it somewhere if not.
<jgrant>Anyways, known of this was my intention ... just thought I spot an error in the README. :^P
<jgrant>a_e: Also, thank you for working on GNOME.
<a_e>Just an accident ;-)
<jgrant>a_e: You need some GNOME tech, or?
<a_e>No, I was just mixing up different packages called *zeitgeist. Now that I started with the gnome one, I may as well finish it.
<jgrant>I sent RMS an email with a domain, and he said "I will send mail to fetch that page.". What does that mean?
<jgrant>a_e: Ah, okay.
<jgrant>Still, neat.
<ijp>jgrant: I thought everyone knew about his, peculiar, web browsing habits
<jgrant>ijp: No, I do.
<jgrant>Oh, he means sendmail?
<jgrant>I thought he meant he was going to send an email to fetch the page ...
<davexunit>he has a script that emails him the contents of web pages
<davexunit>because using a free web browser is too convenient or something
<ijp>or the one that comes with emacs
<jgrant>davexunit: No, it's because he doesn't like Xorg and rarely boots into it, also he doesn't have a readily available internet connection.
<jgrant>He was a "how I do computing" thing floating around somewhere that details all of this, I just forgot how he receives webpages. :^P
<jgrant>I basically sent him the wiki and asked his feelings on some of the names as an alternative to Guixotic; hopefully will ease some tension by effectively "giving us less choices".
<jgrant>I kinda just wish that someone would step up and say "It is Guixotic till at least right before 1.0, get over it." or something, because this is all a bit wearing at this point.
<civodul>jgrant: when i said that, you called me a "dictactor" ;-)
<a_e>Ludovic did this on our mailing list.
<a_e>So for me, the thing is decided.
<jgrant>civodul: As a term of endearment though. :^)
<a_e>I find it rather unappropriate that people unrelated to our project discuss on some mailing list how we should call it.
<jgrant>a_e: The problem is, that if he did on the mailing list, he's not been assertive about doing so here. :^P
<civodul>well, gnu-system-discuss is supposed to be related
<a_e>So unless something convincing comes out of it, I think we can safely ignore their discussion.
<a_e>Well, it is a public mailing list, and I get the impression that random people offer their opinion.
<civodul>that's indeed the case
<a_e>Which is fine, but we need not heed it.
<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>This is basically the last feign of interest I'm taking right now, in regards to it.
<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.
<civodul>jgrant: send a patch!
<jgrant>civodul: I'm just wondering if that's still a good place for it (in gnu.scm).
<civodul>i think so; we'll discuss on the list anyway
<jgrant>I'll have it in by this coming friday at the latest, but this coming week is going to be insanely busy for me so I don't know when.
<jgrant>I can probably at least send the initial work today.
<jgrant>I mean, it's only like 9 loc, iirc.
<davexunit>less typing, more patch sending :)
<jgrant>How do you guys do patches again? Via git format patch?
<civodul>yes, see 'HACKING'
<jgrant>civodul: Will do, ty.
<civodul>good night/day!
<davexunit>later civodul!
*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 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.
<DusXMT>rekado: thanks
<jgrant>davexunit: Okay, sent. :^)
<jgrant>Also, I thank you briefly there; I want to thank you formally here. Thanks a lot, seriously, it'd directly due to your help that I got a patch upstream that wasn't just a package recipe. :^)
<jgrant>it is directly due*
<handheldCar>good luck with the name choice
*jgrant also sent in a sample-os-config.scm to illustrate what this syntactic sugar looks like -- so I hope that helps a bit with instigating a need.
<jgrant>It really does look a lot better, imo.
<jgrant>Hm, it drives me nuts that we have a copr rpm package that doesn't work.
<jgrant>And there's no contact for this guy.
<jgrant>Anyone know a "lantw44" ?
<jgrant>Found his github, not sure why this packages doesn't work.