<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' <mark_weaver>CompanionCube: also, there's no need to set it in the environment of the 'guix' commands. probably better to leave that setting alone. <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. <lfam>As far as I can tell, our only package using jasper is kodi. <lfam>Most of the patches I tried are from Red Hat, which I assume means that are the same as Fedora's. But I will look at that tree. <lfam>I actually got them from the Debian tarball before tracing them back to Red Hat <mark_weaver>I've come to prefer Fedora as a source for security patches, if they have them. <lfam>Okay, I will keep that in mind. <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. <mark_weaver>CompanionCube: give it time. the output is very big, and the daemon needs to hash all those files to do deduplication in the store. <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 <lfam>should take over upstream. <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. <lfam>My solution for now is to not use w3m <mark_weaver>for a long time, I used emacs-w3m extensively, so I have some interest in that package. <lfam>Yes, I thought that guix-devel would take more interest in the situation. <mark_weaver>but the lack of upstream maintenance has caused me some concern, and I don't use it much anymore. <lfam>It's probably not the most important thing to spend time on. With the SSL issues addressed, the w3m userbase is small enough that I doubt anyone is targeting it. <lfam>Indeed, the Fedora CVE patches "build on" non-CVE patches <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. <rekado>it's especially painful over slow NFS. <CompanionCube>rekado, I solved it by only using the single texlive metapackage <CompanionCube>which allowed it to collapse the insanely huge texmf dir into a single link <rekado>still, profile generation time could be improved. <jin_>hi guix, i reconfigure my system.scm and create a new user and can't login session <jin_>i login session only with root user <jin_>in the slim log appear : slim: pam_authentication(): User not known to the underlying authentication module <lfam>jin_: Can you get a shell as root and see if the new user appears in /etc/passwd? <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. <jin_>thanks lfam, i will keep looking for <jin_>the curious is that root user it's wortking <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. <Jookia>Interesting- switching from pre-inst-inv's guix-daemon to a guix-daemon in the Guix store makes it want to rebuild everything <Jookia>Does updating Guix require rebuilding all packages? <fps>Jookia: not necessarily so <Jookia>fps: Hmm, I wonder why switching from a Guix I built in Debian to one I built with that Guix leads me to need to rebuild <Jookia>Is there a package with only one dependency (or none) that I can check to see if it's rebuilding <Jookia>I may have to post this to the mailing list <cajg>Installing GuixSD from the installer... got to mkfs.btrfs: command not found <cajg>now I need to know how to set up a separate /boot on /dev/sda1 in config.scm <mark_weaver>cajg: it seems that no one has yet packaged btrfs-tools for guix. <mark_weaver>and the btrfs module(s) would need to be added to our initrd, and maybe some other minor modifications to our root-partition mounting code in the initrd, I don't know. <mark_weaver>I guess none of this is likely to be difficult, but it hasn't yet been done. <mark_weaver>cajg: setting up a separate /boot is easy enough, just add a 'file-system' declaration for it. see section 7.2.3 (File Systems) in the Guix manual. <cajg>yep, thanks mark_weaver, I was able to insmod the module but couldn't find any tools so went ahead with ext4 <efraim>how do I get the hash of a git reference? <lfam>efraim: I usually just try to build with a garbage hash, and then copy the hash in the resulting error message. <efraim>lfam: thanks, that worked for me <cajg>So, in the installer, issuing "locale -a" I get command not found <cajg>I assume it'd be there or someone would've noticed before <cajg>can't find it though./ Maybe my PATH is incorrect <cajg>Moving on anyway, issuing "guix system init..." gets me <cajg>/mount/etc/config.scm:8:0: error: source expression failed to match any pattern <cajg>which I presume is a parsing error of some kind, but I've checked the file quite carefully <cajg>or perhaps it's a fail on the locale line <cajg>but nano tells me this is line 11, GChriss <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. <jjmarin>Hi ! I'm trying GuixSD for the first time. I've realised there are a lot og gnome packages avalaible, incluiding gnome-shell, I wonder if I can use gnome as my default graphic environment <GChriss>cajg: (device "/dev/mapper/guixsd") <-- is this a valid name? it might be, but caught my eye <lfam>Also, you must use (cons*) instead of (cons) if you are cons-ing more than one filesystem <cajg>Disk /dev/mapper/guixsd 105GiB <cajg>aha thanks, will chase those up <GChriss>cajg : oh, and "mappeddevices" might need to be "mapped-devices" <jjmarin>Any idea how to permanentely mount a partition, /etc/fstab is not what I'm used to in other distros <lfam>jjmarin: What do you mean by "permamently"? Like, automatically at boot? <Jookia>No news is bad news on my Guix problems :( <Jookia>mark_weaver: I have a log of some challenges that failed - is this useful? <lfam>Jookia: Many of the people who could help you with the problem you sent to the list are at FOSDEM or AFK for the weekend. <lfam>I believe we are trying to cooperate with that project <Jookia>My problem is kinda unrelated to reproducible builds tho <lfam>You said you had some failed challenges? The challenge feature is testing reproducibility <lfam>I will say that in the last couple days, core Guix packages were updated, forcing a rebuild of all the other packages. That could be related to your emailed problem. <Jookia>Perhaps, but I'm running an identical version of Guix in almost all three stages. I think. Hmm <Jookia>Given the nature of the issue I can't really figure out what's causing the rebuild