<vagrantc>even the bots are treated nicely around here :)
<ngz>I encounter a problem during the validate-runpath phase of a program. Build fails because a library cannot be found in RUNPATH. Yet, I added $out/lib to CMAKE_INSTALL_RPATH. Any idea about what could go wrong?
<mbakke>ngz: is the missing library present in $out/lib?
<noobly>i try to build a package but get 'no code for module (gnu packages rust-apps), how do I remedy this? rust-apps is not a package
<ngz>mbakke: It is present in the failed build directory (I built it with -K), under "lib/".
<ngz>noobly: Add #:use-modules (gnu packages rust-apps) at the top of the file, in `define-module'.
<apteryx>everything that needs patches to build. Could be IceCat. Could be Emacs. Could be anything, really :-)
<apteryx>rekado_: the quick and dirty thing to do would be to run the whole nfs-service on the client as well. Ideally we should be able te extract rpc.statd to stat that alone. I'll put a note on my todo.
<brendyyn>xelxebar: we both had the same error though right? we might of just had two problems coincidently at the same time
<xelxebar>It's possible. You did mention that you were getting the same error though...
<xelxebar>Just a sec, I will do a pull now and see what happens
<brendyyn>i have set it manually and build and reconfigured with the 5.6.2 kernel already. you can either wait or you can set it in your operating system definition. i haven't tested it but you should be able do something like (kernel linux-libre-5.6)
<vagrantc>GuixGuy: as for applying patches, see the guix manual ...are you familiar with git?
<brendyyn>GuixGuy: you would need to clone the git repo then download the patch from 40190 into the repo, use git to apply it, then build the git repo. then you can reconfiugre with ./pre-inst-env guix ...
<GuixGuy>I see. I started using git about a week ago so I will check out the manual for further info
<noobly>lfam: Yes I'm using guix system. I was wrongly under the impression guix pull upgraded everything - is there a command that just upgrades all my packages and daemons?
<apteryx>rekado_: nevermind about statd being required on a client. There was a ridiculous amount of confusion going on, due to me moving a WiFi USB adapter to a different machine and my AP being configured to set the IP of that machine based on the MAC address of that adapter. Phew. Everything works perfect. Thanks a ton for the nfs-service-type!
<sneek>apteryx, rekado_ says: We should add a separate statd service then. Hard to test this because server and client are the same in the system test.
<sneek>apteryx, raghavgururajan says: For linphoneqt testing, please use new patch v7.
<lfam>noobly: To upgrade the packages your user has installed, use `guix upgrade`. To upgrade the system, including the daemon, do `guix pull && guix system reconfigure /etc/config.scm && reboot` as root
<jsoo>does /etc/config.scm contain your system definition?
<xelxebar>Yes. And it also contains that simple-service line. /etc starts out empty and gets populated somehow, I'm trying to figure out what copies the config to /etc/config.scm and where in the store the original object is.
<xelxebar>Well, the "what" is sort of answered by that simple-service line. I'm just trying to find out where the original is
<jsoo>have you tried guix system list-generations xelxebar ?
<jsoo>that will tell you which configuration a generation was built from
<xelxebar>Um.. perhaps that came out jumbled. The guixsd vm and iso images contain empty /etc directories by default; however, after booting /etc/config.scm exists, thanks to that simple-service line above.
<xelxebar>jsoo: Nice. That looks exactly like what I want. Thanks
<jsoo>i think there's a file in /run/current-system that also points to the current
<xelxebar>Still getting a hang of the basic ropes here
<jsoo>that's a cool idea to add the current config as a skeleton of sorts into a vm xelxebar.
<jsoo>xelxebar: you can follow the link in /run/booted-system/configuration.scm and that should have your current configuration
<xelxebar>jsoo: What about for a non-booted system?
<xelxebar>Perhaps I could point guix to a mount point or something?
<xelxebar>Yeah, I'm trying to hang together all the pieces to make a guixsd Google Compute instance.
<jsoo>there is also /run/current-system/configuration.scm
<xelxebar>Okay, here's another one, are there moral equivalents to dpkg-query -L and dpkg-query -S, i.e. I'd like to find out what files (outputs?) a package provides as well as do a reverse search on these.
<xelxebar>In particular, I am trying to figure out what packages lets one do 'herd start cow-store'
<vagrantc>but it's not immediately obvious what the order is ... to get the linear order you would have to build each and every commit and track the differences, because there's no incrementing version
<vagrantc>you almost have to know the answer to know what question to ask :)
<xelxebar>Well, practically speaking we just want 'guix package --find-file=bin/foo' to return 'baz-9.9' or whatever will get installed with 'guix install baz'
<vagrantc>a database that just periodically gets updated would probably be sufficient to ask "what packages have had bin/foo ever"
<brendyyn>'guix build emacs' only takes 1.5 seconds for me after emacs is already build. so for 10,000 packages thats 4 hours to scan through everything. thats starting from scratch. only 10 minutes or so if say 500 packages have been updated and the rest is cached.
<vagrantc>usually ... although there are some things in /gnu/store that aren't obviously tied to a specific package
<rekado_>instead of scanning we can compute this information when generating the (cached) narinfo files.
<vagrantc>for package in $(guix package -A ) ; do find -type f $(guix build package) ; done
<rekado_>some other process could then index the narinfos.
<rekado_>the only difficulty is that this is a centralized service. So far all of Guix works the same whether it’s run locally or on the build farm.
<vagrantc>successfully built /gnu/store/zpg0xicxynsqpcx64vg3gky32fd58bbm-linux-libre-pinebook-pro-5.6.0.drv !!!
<vagrantc>rekado_: could build a package updated periodically that's shipped in guix itself ... and it's only as outdated as the last time the package was updated
<vagrantc>presuming this database is manageable in size
<brendyyn>i thought that this could be not used as a dynamic service but treated as a package. we release some think like guix-package-data version 2020-04, and that is an input to some bash completion package or GUI package manager
<brendyyn>update that once a month, not a big deal if its a bit wrong sometimes
<eric-guix>I'm trying to understand how to speedup my upgrade. Offload seems to solve the problem but my question is: Offload work in background building my config.scm package? Or it starts only when I launch "guix upgrade" or "guix install" ?
<rekado>eric-guix: offloading only means that builds (when requested) happen on a remote server instead of the local machine asking for the builds.
<rekado>eric-guix: are you downloading binary substitutes from ci.guix.gnu.org?
<rekado>generally you don’t often need to build anything locally because ci.guix.gnu.org provides binaries.
<eric-guix>rekado: I'm using the default server for the binary, the problem that I want solve is the heavy cpu work for my x200 laptop when i launch "guix pull" or "guix update". Exist something that relay on a server to do the job on any git pull change
*kmicu is so happy that alextee[m] is packaging all those audio goodies. Thank you!
<alextee[m]>oh it worked now, the previous link was giving a different hash each time
<civodul>janneke: i realized ext2fs now uses xattrs to store passive translators settings, so in a future interation, we can store them directly when we build the image, in populate-root-file-system & co.
<reepca>Parra: I've got an idea what the problem is. So the 'unpack' phase that is used in copy-build-system is reused from gnu-build-system, where it runs "tar xvf <source>". It assumes this will produce a single directory, the unpacked source directory, and so it chdir's into the first directory it sees.
<reepca>but, having used wget to download the source myself and tried to unpack it, it exploded a bunch of directories and files into existence
<reepca>that would make sense, considering if the unpack phase is left as-is, then the current directory at the time of the copying doesn't have a "host" directory, as it *is* the "host" directory.
<reepca>since the unpack phase happened to pick it as the first directory it saw to chdir into, because it expects the tarball to contain a single directory, not multiple files. It actually chose it as the first directory because it's the lowest one in more-or-less alphabetical order.
<alextee[m]>is there a way to to do a regex on directories and copy them to a destination?
<guix-vits>reepca: (invoke "pwd") in 'install: /tmp/guix-build-netcore-2.1.17.drv-0/host . hm..
<reepca>guix-vits: aye, that matches up with expectations. It should work to just do (modify-phases %standard-phases (replace 'unpack (lambda (#:key source #:allow-other-keys) (invoke "tar" "xvf" source))))
<reepca>hm, I guess another way to make it work would be to "undo" the chdir from 'unpack' by specifying '(#:install-plan '("../" "shared/" #:include-regexp ("\\.dll$"))) (note the "../")
<guix-vits>reepca: i finally got it: in another tarballs, when i'm unpack them, i see a dir. thanks for the explanations
<reepca>providing convenient integration would require tweaking the generated build scripts, which could increase the differences in behavior between the build environment and the debugging environment
<Parra>I don't see how that could affect, because I don't know yet the whole architecture and Implementation of Guix
<Parra>but I think debug can be rolled back later on, and that's it
<Parra>I don't see how a debugger can modify the state, unless you manually modify the state
<Parra>if you are only stepping and seeing the variables.. shouldn't affect the
<mbakke>civodul: I did a merge of master into core-updates yesterday, but did not push it because one test is failing: "package-transitive-supported-systems, implicit inputs" from guix/packages.scm:397
<mbakke>can you have a look if I push the branch somewhere?
<mbakke>the test returns '("i686" "x86_64") when it is supposed to return all supported architectures
<mbakke>ehm I meant: actual-value: ("x86_64-linux" "i686-linux")
<anadon>I started on updating Django yesterday. It looks like that will end up being a minor project and a rather large patch. Should I be breaking it up? I think in this case it should be kept on a monolith.
<NieDzejkob>I assumed you meant "commit hash" for some reason
<NieDzejkob>Also, I've seen you're doing a lot of work with build failures on core-updates. Is there a way I could help with that? I tried looking at the logs from some failing derivations but the /log/ URL returns an empty response
<str1ngs>janneke: there are not many logging procs. I think I can just add a emacsy-log? variable. so it can be turned on and off. should not effect much code this way.
<janneke>str1ngs: okay, good. yes, i hope that most obnoxious "logging" is actually for debug purposes and should be removed at some point; only messages that are actually informational for a user must go to *Messages* i guess
<str1ngs>janneke: right, though it is useful. just not all the time
<str1ngs>janneke: also side note, split window is a hard problem to solve haha. I'm using emacsy windows in nomad now. but widgets are PITA :)
<janneke>str1ngs: sorry for not being more involved; thanks for picking this up
<janneke>str1ngs: yes; this frustrated me for a while, thinking it "should" be easier to solve
<str1ngs>janneke: no problem at all. I'm just cautious when making changes to emacsy. I'd rather have some code review.
<str1ngs>janneke: my solution is to keep only support single window instance for now. I added frame support aka emacs windows which helps.
<janneke>yes, we should really get this right; and that will take some effort
<str1ngs>my thought was to create new GtkTextView's for each new window. this is manageable. for <web-buffer> which is a custom buffer with nomad. I thought of creating a web controller that works on each buffers window. seems like alot of work though.
<lfam>I don't know, I just feel like it should reflect the upstream version number
<noobly>so I'm getting this eror: "guix package: error: cannot install non-package object: #<unspecified>", and I read that 'the problem is likely that the file doesn’t evaluate to a package object, but to #<unspecified>, so end it with ‘magic-enum’, which evaluates to a package object', but I don't know how to implement that advice, any tips?
<lfam>noobly: Put the text 'magic-enum' at the end of the file you are working on
<mbakke>civodul: making the new test fail by changing a version number lets "package-transitive-supported-systems, implicit inputs" pass ... I am kind of hoping my computer is going nuts, as I really don't see a relation between the two tests.
<mbakke>would be good if someone could try and reproduce the issue to confirm whether my computer has been ingesting illicit substances behind my back :P
<mbakke>lfam: can you try to cherry-pick 190ddfe21e3d87719733d12fb9b5eb176125a49f and a187cc562890895ad41dfad00eb1d5c4a4b00936 on core-updates and run 'make check TESTS=tests/packags.scm'?
<bgardner>Good afternoon guix! I'm getting a new error on a box during 'guix system reconfigure' after a 'guix pull' - and nothing changed in the config.scm. The fail message is "builder for `/gnu/store/...-etc.drv' failed with exit code 1 - the actual error in the log is 'ERROR: In procedure symlink:\nIn procedure symlink: File exists'
<bgardner>I do have two simple (extra-special-file ...) sections, and other guix boxes without these sections have no such error.
<civodul>bgardner: did you see the message related to rottlog in "guix pull --news"?
<joshuaBPMan>That's the startup error I got when I open icecat in a terminal.
<joshuaBPMan>guix-vits: I probably can. I'm honestly not interested in trying that though. I'd have to reconfigure a lot of stuff to pull that off. If you can convince me that it would be worth the effort, then I might try it.
<rekado>joshuaBPMan: do you see the same behaviour when using “icecat --safe-mode”?
<joey>Hello. I am thinking of installing Guix again, but for my Thinkpad X200, I wasn't able to get the volume buttons to work nor the touchscreen. Does anyone know if there are some specific drivers that are needed for these actions?