<DynastyMic>Can I install some software without packaging it?
<bjc>you are probably going to run into issues trying to install something from ‘make install’ or its like
<bjc>it depends on the software's expectations, but traditional unix binaries that expect to live in /usr won't work
<DynastyMic>Yeah, when I run the installation script, I get /home/users/allegro-graph/agraph-7.3.0/install-agraph: No such file or directory
<bjc>you may be able to tell it to install in your home directory or some other, non-guix managed place (eg /usr/local) by passing a ‘--prefix’ argument to configure, or flags for whatever it uses to install
<vagrantc>though i just stuck that in a for loop after "parsing" a .json dump of unreproducible packages from data.guix.gnu.org
<bingulo>hi folks, i'm trying my first guix install today. i'm following the manual install method and is in "guix system init" command part. after reapir some issues on my config.scm, I cannot get any informative error other than "failed to load 'config.scm': invalid argument". what that means?
<nckx>bingulo: Is there really no other output? What's the exact command you're running?
<nckx>Even when it becomes one, you'll have to talk to <https://github.com/lathiat/nss-mdns> to implement it. I can't imagine they'll be open to removing .local, though, and .local will always remain unallocated because of its decades of use for this.
<nckx>bingulo: I got distracted by hot DNS chat. I don't know why it didn't throw an error early. Maybe the compatibility code (the field used to be named target, singular, and took a single argument) is too eager? Etc.
<tom1192>Hi. I'm trying to connect to a Matrix server via Weechat. I've installed weechat and weechat-matrix to my system environment, but my weechat is unable to find the plugin/script via '/plugin' or '/script'. Does anybody know how to help weechat find weechat-matrix?
<tom1192>I guess most weechat plugins are in the right plugin path, by virtue of being in the correct /gnu/store/*weechat/* directory, and weechat has no awareness of /gnu/store/*weechat-matrix*/ ?
<tom1192>I see /run/current-system/profile/share/weechat/python/matrix.py exists, so presumably weechat has awareness. I'll try to trace through the relevant load paths.
<tom1192>/python load /run/current-system/profile/share/weechat/python/matrix.py <<<< worked! (Just the basename did not.)
<tom1192>Stracing weechat, I can see that it's not looking in any directory under /run/current-system. I'll raise this as an issue.
<apteryx>tom1192: try installing weechat and weechat-matrix to your *user* profile
<apteryx>otherwise the bug you encountered is already known as #20255, the oldest bug in GNU Guix
<tomog[m]>I see that there are two types of kernels: -generic kernels, which use defconfig, and non-generic kernels, which use a kernel from aux-files. Why do both exist? Is the idea that we are in a transition step towards there being just one type?
<denna[m]>I saw this video https://m.youtube.com/watch?v=S9V-pcTrdL8 i wonder if it is true that guix dont have modules in the sense of nix. I saw something similar for the basic System Continuation in the documentation but have not seen hif/ow user applications can be configured by guix.
<unmatched-paren>denna[m]: i'm not sure how nix modules work, but if you're talking about traditional modules, guix uses guile's module system.
<jpoiret>zamn, i don't know what's wrong but both ripgrep and git grep (and gitlab search) ignored that
<sughosha>jpoiret, nckx: thanks for both of you for taking your time to help me. I found out that `games` channel I used refers to libpng-1.2, I just grepped the channel's git folder and found this out. I will report them.
<civodul>unmatched-paren: (local-file "." "dir" #:recursive? #t) should be enough
<nanounanue>just edit and then repackage and then import it?
<unmatched-paren>you'd bind the new package to a variable (define python-mypkg (package ...)) and return it at the end of the file with `python-mypkg`. you can test it by running `guix build -f guix.scm` or `guix shell -f guix.scm`
<unmatched-paren>civodul: that wouldn't work if you're in, say, src and you run `guix build -f ../guix.scm`, would it?
<nanounanue>should I create and environment I supposejow do I mix the manifest.scm and the guix.scm
<nanounanue>there are also some missing python packages in the guix, but I can import them from pypy
<unmatched-paren>nanounanue: the ones that are required to build your package should be given as propagated-inputs in the (package ...). (usually you'd use inputs or native-inputs but python is --annoying-- different)
<unmatched-paren>the ones that aren't required, but helpful in development, should probably go in the manifest
<unmatched-paren>by the way... does anyone else think a --backend=list would be helpful for guix graph?
<nanounanue>if I am defining several packages, I should return them at the end of the guix-package, right?
<unmatched-paren>it would output a textual list of packages, and the packages would be sorted into an order such that packages only depend on packages below them
<unmatched-paren>nanounanue: are there literally multiple possible buildable packages, or are those other ones just dependencies?
<unmatched-paren>also, `--module` and `--not-module` flags; `guix graph --not-module '(gnu)' foo` would return all dependencies of foo that are not in the gnu module
<unmatched-paren>then, if somebody wanted to upstream a package from their own channel, they could do `guix graph --backend list --not-module '(gnu)'` to get a list of everything they need to upstream
<unmatched-paren>and the list would be sorted such that if they went down the list, upstreaming and committing one package at a time (as you're supposed to do), there would be no commits that don't work
<lilyp>unmatched-paren: that makes things somewhat easier
<unmatched-paren>nckx: if you thought go-github-com-protonmail-go-crypto-openpgp was bad, how about go-github-com-protonmail-go-crypto-internal-byteutil?
<nckx>Michal_Atlas[m]: Yep, with (package-version this-package).
<nckx>Use #$ or , according to how your (arguments …) are written.
<nckx>unmatched-paren: Assuming go-github-com-protonmail-go-crypto-openpgp uses go-github-com-protonmail-go-crypto-internal-byteutil, and we discover a bug in go-github-com-protonmail-go-crypto-openpgp that requires a patched version of go-github-com-protonmail-go-crypto-internal-byteutil, we'll have go-github-com-protonmail-go-crypto-internal-byteutil-for-go-github-com-protonmail-go-crypto-openpgp.
<unmatched-paren>nckx: beautiful, but sadly go-crypto-openpgp doesn't depend on go-crypto-byteutil
<Michal_Atlas[m]>I noticed that chicken-status marks a lot of eggs that I tried adding as "unknown-version" which seems to happen whenever eggs don't include that in their .egg file, which is most of the times. So I thought I could just include it if it isn't in there, to fix the problem, hopefully it being a learning experience.
<nckx>I'm on shaky ground here but I think you'd have to use hyphen-separated-name->name+version?
<nckx>The ? is not part of the name, just part of me right now.
<nckx>Basically, at this point & level, the niceties of package records have been replaced with the hard reality of the store, and you need to ‘parse’ the /gnu/store/hash-name-version file name to get the info.
<kaelyn>maximed: Thank you for the example! I'm guessing I didn't have the #~ and #$ in the right spots
<maximed>foobarxyz: What does ‘stat guix/scripts/lint.go guix/scripts/lint.scm’ say?
<kaelyn>I ran into the problem trying to improve the guix.scm that's in the emacs-guix repo. I was trying to rewrite it with gexps to add its extra phase to the phases from the inherited emacs-guix, to replace it appending a second #:phases keyword to the argument that also just modifies %standard-phases
<maximed>(this catch-all 'misc-error seems suspicious to me, it doesn't match the error message below -- what if the command actually exists, but (guix scripts command) has a line throwing a 'misc-error for whatever reason?)
<maximed>foobarxyz: oops I shouldn't have put a ( ... ) around command
<foobarxyz>So far I've done guix pull, and updated to the late guix source, and done make clean, bootstrap, configure, make, but the issue persists; guix is at /home/foobarxyz/.config/guix/current/bin/guix, and I'm running on ubuntu
<foobarxyz>nckx: I've just tried `./pre-inst-env guix lint gcc` from withing a `guix shell -D guix`. It also worked from withing `guix enviornment guix --pure`; I think it must have worked because of the final gi tpull I've done to the guix source
<nckx>foobarxyz: Nothing relevant has changed in Guix since you said you ‘updated to the late guix source’ earlier, above, so I'm not convinced. I'm glad it works for you! But if there is a bug, it hasn't been found or fixed.
<foobarxyz>unmatched-paren: ok I see what's happening outside the guix shell ..., picking up on maximed's hint, somehow I am missing the `guile-json` package. Once i `guix install guile-json`, it then works
<nckx>unmatched-paren: It works if you have all the required guile-* packages available in your regular profile, but that's not guaranteed, so ‘guix shell -D guix --’ is always safer.
<nckx>11 Jun 22:48:29<nckx> What's $GUILE_LOAD_COMPILED_PATH in the environment?
<nckx>unmatched-paren: Appreciated, but in this case both are fine.
<foobarxyz>here it is: `GUILE_LOAD_COMPILED_PATH=/home/foobarxyz/.guix-profile/lib/guile/3.0/site-ccache:/home/foobarxyz/.guix-profile/share/guile/site/3.0:/home/foobarxyz/.guix-profile/lib/guile/3.0/site-ccache:/home/foobarxyz/.guix-profile/share/guile/site/3.0`
<foobarxyz>nckx: I can continue my work with `guix shell -D guix`
<nckx>The issue is that ‘guix shell -D guix’ sets GUILE_LOAD_PATH to a directory that contains all the guile-* packages you need, including guile-json. You can verify that by looking in /gnu/store/fby3hf4sbmmb4zxlxmjkfs56pg7ghxsl-profile/share/guile/site/3.0, which is the correct value. But when your shell starts and loads its configuration files, something clobbers (overwrites) GUILE_LOAD_PATH so it no longer points to those modules.
<unmatched-paren>justkdng: ...on systemd-announce: "systemd renamed to system. we are proud to announce that systemd is now the world's second most bloated kernel, surpassed only by the Windows NT kernel"
<nckx>That's the root problem. I just don't know where to look for the cause on non-Guix Systems.
<unmatched-paren>(although apparently the NT kernel is actually a hybrid micro/monokernel
<foobarxyz>nckx: yes i can confirm this, the only packages that are in /home/foobarxyz/.guix-profile/share/guile/site/3.0, are those that are installed as given by the `guix package -I|grep guile` command above
<nckx>foobarxyz: The problem is that ‘guix lint gcc’ won't lint the gcc in your git checkout directory, it will lint the gcc package that's part of the ‘guix’ you're invoking.
<nckx>So I don't think it's what you actually want? You can add a ‘mistake’ to your checked-out hello package, like making the synopsis empty, to test. ‘guix lint hello’ won't catch it; ‘./pre-inst-env guix lint hello’ would.
<nckx>You can work around this but the root problem remains.
<nckx>And will probably bite you again in different ways.
<foobarxyz>nckx: it is perhaps that the `guix` command refers to all the guix dependencies on the store, but the `pre-inst-env guix` only looks what is in the ~/.guix-profile/share/guile/site/3.0 directory?
<nikola`>unmatched-paren: well systemd would also be a microkernel in a way
<foobarxyz>nckx: courtesy of GUILE_LOAD_PATH which points to ~/.guix-profile/share/guile/site/3.0 ?
<foobarxyz>nckx: I think this could explain it (probably this is what you have been saying all along and I've only now realised)
<Michal_Atlas[m]>If I were to have two patches and one depends on another, how should I go about submitting them?