<minall>What can you say to me about the .m4 fileformat, for what it is used?m I'm searching information about it, and it seems to be a 'File TypeMacro Processor Library', though, I can't find the reason of usage.
<buhman>wow, that is quite interesting! the documentation calls itself an "extension", but as a novice guix user, the implementation looks like some convenience functions over existing packaging primitives.
<buhman>.. which is actually exactly what I had imagined.
<xavierm02>jfred: It could scale if enough people used it, but if you need to punch holes for every program you use, it'll be pretty hard. I've thogh a bit about it and I think that guix packages should know which files / folders they use in the user's home.
<xavierm02>And then, the package installer makes the program use files in ~/.guix-home/<package-hash>-package-name/<thing> instead of ~/<thing>, where ~/.guix-home is readonly ~/<thing> is a symlink to ~/.guix-home/<package-hash>-package-name/<thing>.
<xavierm02>And when you upgrade the package, it copies those files to the location with the new hash, so that if the new version deletes stuff / ruins your files (such as history and bookmarks in icecat for example), you can still recover. And if the new version converts some file to a new configuration format that's not backwards compatible, then you can still run the old program with the old config
<xavierm02>And as a bonus, you can fully encapsulate programs, and not give them access to the user's home. With packages handling this, you can use packages that handle this with package that don't without punch holes yourself (since the real home is not readonly).
<xavierm02>(Well in reality, you probably wouldn't want ~/.guix-home to be readlonly, just some files in it)
<rekado_>jonsger: don’t know how long the delivery takes.
<jonsger>This time-error is only happening in guix 1.0.1 and gone in guix-weekly (build from recent master commit)
<jonsger>efraim: the other error is "guix system: error: cloning builder process: Operation not permitted" when guix needs to build some software. This is due missing capabilities of docker. I didn't found the parameter yet or forgot it...
<xavierm02>So the problem with icons missing in LyX if qtsvg is not in the profile looks like it gets fixed by adding the qtsvg path in QT_PLUGIN_PATH with a wrap-program.
<xavierm02>It seems to be a common problem and there are slightly different versions of that fix for several packages using qt. The wrapping looks pretty odd. Shouldn't the QT_PLUGIN_PATH instead be set in the profile?
<xavierm02>With search-path-specification? (I'm not entirely sure what this does yet, but it looks like it could help)
<runejuhl>Hi all. Is there a good way of making available a back catalogue of package versions so any version, previous or current, can be installed? As I understand it the git package repo (usually) only contains a single version of a given package.
<xavierm02>runejuhl: Idk but "inferiors" should be a good keyword to search about that.
<efraim>runejuhl: it's also possible to package older versions of packages
<xavierm02>I think that the next things I'll try are: (1) Look at making qtsvg export stuff so that all other packages that depend on it can stop wrapping. (2) Try to add a --no-building option to guix package
<rekado_>minall: technically, the build is done from a derivation. A package definition is first compiled down to a derivation.
<xavierm02>(But if those things look too hard for a newbie, I'd be happy to know it)
<bavier>xavierm02: iirc the suggested option name in the past has been --only-substitutes
<minall>Thank you, It was just a question for curiosity
<minall>I'm trying to understand the inner working of the driver xf86-video-openchrome, any suggestions for a newbie?, they have a lot of .m4 files, I researched a little and it seems to be to make macros, but why m4 is used instead of other filetype?
<bavier>minall: the .m4 suffix is usually used for files intended as input to the m4 macro processor
<minall>sorry for my ignorance, m4 macro processor do you mean any processor? because in that case it makes sense it is used...
<bavier>minall: see 'info m4' or 'guix package --show=m4'
<raghavgururajan>roptat It is so easy for me that xmpp being extensible. I do irc via xmpp-irc (biboumi) gatway and so SMS via xmpp-sms (cheogram) gateway. Soom I will be using matrix and sip with xmpp. :)
<leungbk>Many of the web/json-related tests are failing for me right now, including many package-related ones. If I run `(lookup-origin "http://github.com/jgm/pandoc.git")` or similar in the Guile REPL after importing `(guix swh)`, I get #f.
<leungbk>I'm guessing this is related to the Guile-json upgrade, but it's difficult to debug this with the REPL alone.
<rekado_>leungbk: do you have any version of guile-json installed? If so: which?
<leungbk>@rekado_ Yes, Guile-json 3.x to comply with what's expected on the Guix master branch.
<lfam>Lukas4452: It sounds like the cow-store service isn't working right. If that service is failing, then you will be limited to RAM
<xavierm02>So since instealling all of guix's dependencies didn't work to avoid having to "guix environment guix", I have resorted to a bash alias. But it's still pretty slow. Is there some way to speed it up?
<Lukas4452>I will write some "nice" comments in that config.scm
<xavierm02>rekado: My main reason was laziness. But with a bash alias and --root everything it's already nearly perfect. One thing I really disliked while I was using fish is that it doesn't have the [env] thing so I never know where I was, but now I switch back to bash so that's one less reason
<roptat>Lukas4452, if that works, would you like to write to that bug (email@example.com) to say you hit the bug too?
<nixo_>rekado: I think I was not clear. It's creating the tarball, but I get: ./opt/gnu/bin/R: bad interpreter: /gnu/store/q19l04vd2za80mk1845pz7r8cz29qk43-bash-minimal-4.4.23/bin/bash: no such file or directory
<xavierm02>Is there no vi package? (I know there are many variants but some programs (e.g. git) just really want to open vi (at least when EDITOR is not set) so if there's a package I'd like to install it in case I need it someday
<lfam>xavierm02: There are the vim, vim-full, nvi, and neovim packages
<avocadoras>"By default, Emacs (installed with Guix) “knows” where these packages are placed, so you do not need to perform any configuration. If, for some reason, you want to avoid auto-loading Emacs packages installed with Gui..."
<nckx>Guix's emacs package does some patching (‘Make sure Man looks for C header files in the right places’, ‘Use 'guix-emacs' in "site-start.el". This way, Emacs packages provided by Guix and installed in ~/.guix-profile/share/emacs/site-lisp/guix.d/PACKAGE-VERSION are automatically found.’).
<dutchie>and stuff i have installed via use-package and melpa works fine
<nckx>avocadoras: That's probably what that paragraph is referring to.
<dutchie>(although it's on my lengthy todo list to make guix definitions for the packages that aren't available yet)