<maximed>If it is on Debian, you can do "apt-get update && apt-get upgrade" to upgrade the system-installed guix to 1.2.0
<maximed>(I'm assuming you are using the Debian package)
<mekeor[m]>or maybe clone the guix repository and build and install it yourself
<poet>maximed: I can't remember, my friend, It has been a couple of years. I *think* I used a shell script from Guix's site, but I'm not 100% sure. And no, I'm pretty sure I didn't use Debian to install it.
<mekeor[m]>or maybe remove guix completely first (i.e. rm -rf /gnu/store, i guess?), then install it again
<poet>I wish there was a better way. Seems awfully drastic. Oh well. I'll update Debian and see what happens. If that doesnt work, I guess I'll start wiping directories.Not like I have anything better to do. Thanks for trying to help. I appreciate it.
<vivien>If there are different nss-certs directories in /gnu/store, let’s say /gnu/store/aaa-nss-certs and /gnu/store/bbb-nss-certs, it will copy /etc/ssl/certs and /gnu/store/aaa-nss-certs/etc/ssl into /gnu/store/bbb-nss-certs/etc/ssl
<b3>dstolfa: Thanks! Do you know where exactly I set this? I am using openvpn-client-service-type which I think has already configured the shepherd-service to auto-start so I'm not sure how to change it
<dstolfa>b3: hm. i'm not actually sure. i don't think the discussions around making services extensible was pushed. you might have to "override" the service by manually creating one and creating your own service type. alternatively, you may be able to do the same thing that openssh-shepherd-service does, which is expose an auto-start (somewhat) in the configuration record
<b3>Makes sense, thanks for the info. I'll just manually override it for now with my own service type :)
<shoshin>anyone know if there's an irc bouncer service for guix?
***GPLv3 is now known as Noisytoot
<drakonis>shoshin: well, i use weechat as a bouncer
<drakonis>there is a znc package but no service afaik?
<apteryx>lilyp: for one thing its .pc file requires it I think
<apteryx>and it makes sense; librsvg's mean to become useful is to be dynamically loaded by gdk-pixbuf
<apteryx>I'm writing a profile hook for the gdk-pixbuf loaders.cache file
<apteryx>so with this change, we can deprecate gdk-pixbuf+svg in favor of librsvg (which propagates gdk-pixbuf)
<vijaymarupudi>Hello #guix, I have a beginners question. I have installed guix on my Arch Linux distribution as root and it seems to work well for the root user. However, when I'm a regular user and try to use it, it reports an error loading the shared library libffi.so.7. I suspect this is a common error so I wanted to ask if I was doing something wrong?
<vijaymarupudi>Maybe it has something to do with not having a profile for this user? The getting started guide doesn't mention anything like this
<iskarian>vijaymarupudi, guix operates essentially independently for different users
<sneek>iskarian, excalamus says: Hey, it's been like a month, but I finally finished my write up. After reworking my website, the site generator, hacking together some CSS to represent diffs, and then remembering what the heck we did, the build experience preserved at http://excalamus.com. I've got some follow up questions for next time you and I are able to talk. I appreciate your help and wanted to give an update from the ether...
<iskarian>the exception is "sudo guix" operates as the current user, not root
<vijaymarupudi>iskarian: Does that mean I have to install guix for each user?
<vijaymarupudi>The guide seems to suggest that the root user installing it and making it available for other users is fine?
<iskarian>mmm, guix itself can be installed by root, I was meaning the operation of guix
<vijaymarupudi>iskarian: Ah I see, indeed `sudo guix` appears to work. Can I make it work without sudo?
<iskarian>if you repeat all the e.g. "guix install" steps as your current user, that should do it
<apteryx>vijaymarupudi: you could export the profile's manifest and the install that
<vijaymarupudi>iskarian: I'm not sure what the guix install steps you're referring to are, I suspect this is because I use the install script
<apteryx>(sorry, didn't read back much, my answer is in the context of migrating a root profile to a user profile)
<apteryx>bah, sticking '(define-public gdk-pixbuf+svg (deprecated-package "gdk-pixbuf+svg" librsvg))' in (gnu packages gtk) (after removing the definition for gdk-pixbug+svg) throws a 'error: librsvg: unbound variable' at runtime
<apteryx>seems like there's a cycle caused when trying to use librsvg at the top level of the gtk module
<vijaymarupudi>Just for future reference if people google errors, my issue with libffi.so or libgc.so not being found with guix was because my LD_LIBRARY_PATH had a stray `:`. This didn't cause issues with any other problem (odd...), but fixing that fixed the issue.
<apteryx>vijaymarupudi: oh, neat! so this problem had nothing to do with Guix, right?
<PurpleSym[m]>I’m trying to figure out why the daemon’s `--disable-deduplication` is broken (see #50121). Is there someone with insight into why there’s two pieces of daemon code able to start a substituter?
<PurpleSym[m]>There’s `LocalStore::substituter()` and then very similar code in `build.cc`, which passes the `deduplicate` option, but apparently is not used, because a substituter is running already.
<b_>It may have been a mistake to update all KDE packages on master, since it only has gcc7. with core-updates-frozen there is gcc10!
***b_ is now known as brendyn
<brendyn>is anyone able to merge master onto core-updates-frozen again? is that the way things are done?
<nckx>No, that wasn't it. /tmp/guix-build-custom-haskell-semigroups-0.19.2.drv-0/package.conf.d/base-22.214.171.124.conf really doesn't exist, and I don't know what's supposed to create if it's so mandatory (is it?).
<ruffni>i thought Guile was the language of choice here ;)
<nckx>C is more functional. Guile only has lambdas.
<PurpleSym[m]>Haskell is a very nice language to teach students algorithms :)
<apteryx>lilyp: actually, the loaders.cache need to be produced both at the build system level and profile, because 1. it may be needed at build time 2. a guix environment (which is basically a profile) can mix any components not known in advance
<ruffni>attila_lendvai: not an expert, but the clause: "Neither the name of Google Inc. nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission" gives me the impression that it's a non-standard (think: roll-your-own) license
<attila_lendvai>ruffni, thanks! hrm... do you have any advise which guix license to pick for this in the package declaration?
<attila_lendvai>it also says: "I've forked the XGB repository from Google Code due to inactivty upstream."
<attila_lendvai>hehh, and this: "Unless otherwise noted, the XGB source files are distributed under the BSD-style license found in the LICENSE file."
<maddo>hello, I have a question about how guix can work with a framework that has plugins
<maddo>basically, guix packages vapoursynth (an old release at this point, but recent release has changed its api and broke most plugins, reluctant to update), which is near useless on its own, but it has several "plugins"
<vijaymarupudi>Optimization and speed are in direct conflict, so finding a balance is difficult.
<attila_lendvai>usually i get annoyed when the debugging facilities are holding me back, and get into hacking on them, instead of the project i'm working on. but hacking on the backtrace of yet another lisp feels too much of a detour for me at this point. i've been there too many times...
<attila_lendvai>nckx, i'm new to scheme. i mostly worked in CL, and hacked primarily on SBCL, including its error handling and debugging facilities.
<nckx>I sympathise, but improving Guile rather than forking Guix to run on another Scheme is the more fruitful approach here.
<attila_lendvai>vijaymarupudi, this is much more simple. judging by its look the backtraces are simply cut at list depth 2, and i couldn't find a way to make them more verbose
<nckx>attila_lendvai: Ah, never used CL I'm afraid (wholly due to prejudices of my own, which are almost certainly bogus).
<attila_lendvai>nckx, ok, understood. then i'll get back to debug prints... which reminds me that there's no logging infrastructure either.
<vijaymarupudi>attila_lendvai: That's a very fair concern, but fixable, as others have said. Inlining probably makes it difficult
<nckx>attila_lendvai: Have you asked in #guile or on a Guile mailing list? It's true that Guix tends to have the larger and therefore more responsive community but we tend to know less about the lower-level Guile implementation.
<nckx>attila_lendvai: I didn't mean to imply that Guile is the best (or even good enough in places). Just that improving it will benefit more people the most. Oh noes, I've become a utilitarian.
<attila_lendvai>if backtraces of all things are lacking, then i guess there are a million more issues with basic infrastructure in guile. everything can be fixed, of course... the only question is how much duplicate effort is wasted in the process.
<attila_lendvai>but i don't want to be a PITA. so, to sum it up, the guix codebase badly needs logging facility, reasonable backtraces, auditing for not unwinding the stack at every corner, and in general better debuggability
<nckx>I don't know if it's what you mean, but you risk (and IMO do) coming across as ‘Guile isn't good enough and therefore should be discarded’. Which, OK, valid opinion, I guess, but it will get you a certain predictable result when you throw it over the wall of a community built around Guile.
<attila_lendvai>well, i had no idea people here are attached to guile, or that guix is so much interdependend on guile. until now i looked at guile as a random scheme that brings guix alive, nothing more, nothing less.
<hiruji>fun fact GNU maintains 4 scheme implementations (5 if you count Mes :)
<podiki[m]>attila_lendvai: I too really like CL and SBCL and have found the backtraces here not as helpful. but I wonder what things are like using a REPL, as I haven't done that for my limited guix (package) hacking
<nckx>There is a lot of community overlap, and the choice for Guile was very much not made by an outsider evaluating all then-available Schemes for debuggability. I wouldn't call myself attached to Guile. I don't think you have to be to believe that porting Guix is a poor fix.
<clacke>hiruji: which ones? guile, mes, GNU Scheme, ..?
*nckx swears out loud at Guile at least weekly. It keeps my skin fresh and young and my neighbours confused.
<hiruji>clacke: guile, gnu/mit scheme, kawa, scm, and mes
<attila_lendvai>podiki[m], guix repl and geiser feels very rough compared to slime and sbcl. maybe i'm just missing the required knowledge, though.
<ecraven>I don't use guile myself very much at the moment, thus it isn't as well-supported as it should be
<hiruji>I didn't have a good experience with the compat layers... they felt incomplete
<podiki[m]>at the very least I find Guile code very readable (as a lisper), which is always very helpful to me
<janneke>"<attila_lendvai> so, guile has useless backtraces... "
<janneke>attila_lendvai: are you compiing your guile programs?
<attila_lendvai>ecraven, i used to hack a lot on slime/swank, too. but my main project currently is packaging bee (of ethswarm.org) and make it easy to start multiple nodes to join multiple swarms... hacking guile backtraces is just too many stack levels away from that... :)
<janneke>the interpreter is known to have lacking backtraces, but you are welcome to send a specific bug report to firstname.lastname@example.org
<janneke>"backtraces are useless" is eh, kind of useless as a bug report ;)
<attila_lendvai>janneke, i can't really answer that, but every single backtrace that i've looked at is full of _ characters at argument positions that would be interesting to be.
<hiruji>I remember scratching my head at a one of guile's backtraces for way too long over a simple type error
<hiruji>record slot wanted a list, not a symbol, ha
<podiki[m]>janneke: would general reports of something like: here is the backtrace, the code, and actual problem that fixed it be useful (not a bug exactly, but need for more precise or helpful message)?
<hiruji>I think a more useful bug report would be one that takes a look at guiles architecture and comes up with some ideas of why things are the way they are :)
<ruffni>i'm running into "#<record-type <operating-system>>: record ABI mismatch; recompilation needed" trying to build guix on wip-risc (it comes from gnu/tests/install.scm). any ideas what i should be looking for in install.scm?
<nckx>ruffni: Probably nothing. You're building from git, right? Have you run ‘make clean go’ and rebuilt Guix?
<nckx>The error means that a record definition has changed and the compiled objects no longer match.
<rekahsoft>Hi all, I am a little confused why a package transformation isn't being applied when I have it as part of a manifest but it is when its defined in a file or is built via 'guix build ...' with the appropriate package transformation option/s.
<rekahsoft>'guix build --without-tests=emacs-org-super-agenda emacs-org-super-agenda' works as expected
<rekahsoft>'guix build -f file.scm' works as expected; file contains (left out module includes for brevity): '(define transform--emacs-org-super-agenda (options->transformation '((without-tests . "emacs-org-super-agenda")))) (transform--emacs-org-super-agenda (specification->package "emacs-org-super-agenda"))'
<rekahsoft>However, putting the same file contents in a manifest and referring to the transformed package does not work.
<maximed>sneek: later tell ss2: If you error: see "ungexp: unbound variable", that means the variable ungexp is unbound but you're trying to use it anyway, so you need to import the module that defines it.
<nckx>MeowcatWoofWoofF: Do you mean running ‘make install’ by hand? That will usually work (modulo many Makefiles assuming /usr etc. already exist) but you'll lose all the Guixiness. Writing a simple Guix package is really the recommended and assumed approach to installing anything on Guix System.