<mark_weaver>do you understand how environment variables work? every process in the system has its own set of environment variables, and spawned processes typically inherit them from their parent processes.
<mark_weaver>so setting the variable in your shell here has no effect on its value in the 'guix-daemon'
<lfam>mark_weaver: I looked into the CVE reported against jasper by the linter. It turns out that jasper has a TON of CVEs against the current version, and not all of the patches I can find apply cleanly.
<mark_weaver>lfam: one important thing when looking through Debian's or Fedora's patches is to generally avoid unnecessary patches, ones that aren't related to security, obvious bug fixes, or deterministic builds.
<lfam>Yes, I'm only looking at the patches that address a specific CVE
<lfam>Both Debian and Fedora have patches that address other bugs, which I have been ignoring. I suppose that could screw up the application of the patches I am trying to apply.
<mark_weaver>sometimes I take some of the other bug-fix patches. it's a judgment call, I guess.
<mark_weaver>with software that's been unmaintained for a long time, I tend to more freely take those bug fix patches.
<lfam>It is a judgment call. I wasn't sure what Guix's stance was, since my proposal to adopt Debian's extensively patched version of w3m was rejected. Some of these abandoned C packages have been patched very heavily by distros who are using static analysis tools and fuzzers.
<mark_weaver>mmm, I wasn't paying attention to that w3m thread, I should probably take a look.
<lfam>mark_weaver: The problem with w3m is that it doesn't have an upstream anymore and it is really bad. The issues go way beyond that old bug report that got me interested in the first place. I am still thinking about how to best address it. I have contacted all the old maintainers and the one that responded said that he is no longer a working software engineer. The rest ignored my email / didn't see it. I think that the Debian developer
<mark_weaver>lfam: although we try to stay close to upstream, for packages that are not maintained upstream (e.g. if they have long-standing security bugs that haven't been fixed in an upstream release), and if there's a simple bug fix in Debian or Fedora that seems clear and unlikely to cause problems, I would tend to take it.
<lfam>The Debian person suggested I package his repository but did not reply to my suggestion that he try to contact the old upstream to get permission to take over the Sourceforge page
<mark_weaver>lfam: I might look into the w3m situation and chime in to that thread (even if a bit late), but it may be a while before I can do so.
<myglc2>Yo, from naked HW to pretty... pretty... pretty... cool headless server config... I am lovin this!
<CompanionCube>wow, ever since installing texlive my profile creation time has skyrocketed
***mog_ is now known as mog
***bmpvieira_ is now known as bmpvieira
***zimmermann_ is now known as zimmermann
<lfam>Oh man. I have been using nixos on an ec2 instance because I wanted a totally declarative system in that environment. But it turns that I can't do the nix equivalent of `guix package -A`, `guix package -s`, or `guix package -i` because the resulting process uses all the available RAM on the system (~900 MB) and the kernel kills it. I asked on #nixos and it is expected that those operations will take some hundreds of megabytes of memory. I
<lfam>hope that we are not going to hit the same problem when we have a comparable number of packages.
<rekado>CompanionCube: I noticed that too after installing LibreOffice. The more files there are in a profile the longer it takes to build a new generation.
<lfam>Hm. I've never used slim and I'm not a PAM expert so I can't offer very much help. But at least the reconfiguration did create the new user. Did you have any luck searching the internet for the error message?
<jin_>yes i find some about sudo configuration file
<lfam>Do you know a way to test PAM from the console? My GuixSD system is headless / doesn't have graphics. I could try creating a new user and see if PAM works.
<lfam>jin_: It is curious and I want to figure out if it is a bug in GuixSD, or in PAM, or slim, or somewhere else. But I have to go AFK for a few hours. You might consider sending a message to the mailing list since user logins are obviously important
<lfam>Later I will try creating a new user in my headless server and authenticating with PAM, once I figure out a way to test PAM.
<lfam>cajg: Can you share your config.scm on a paste site such as paste.lisp.org?
<cajg>how could I do that from the installer, lfam?
<lfam>cajg: That's a very general question ;) You don't have a copy of it on a computer with internet access? It's a good idea to do that because (AIUI) the "config.scm" will not appear in your built GuixSD system. So, if your only copy is on the installer system, you will not have a copy anymore after you build.
<lfam>Anyways, that error message means the Scheme code in the file is malformed somehow
<cajg>I can't see any tools in the installer for getting the config.scm to another computer
<cajg>I did assume it would be copied to the installed system somewhere
<cajg>I copied the edsktop example config.scm and edited it
<lfam>You could try to copy the file off the installation system with a USB flash drive, for example
<lfam>Or, you could copy the file "by hand" onto the system you are chatting from
<lfam>The best course of action is to initialize the system with the example *unchanged*. Then, start making your change and reconfiguring based on the example.