<apteryx>for some reason I had to restart the last time I messed with network-manager plugins. It had something to do with the plugins being made available through some environment variable which would only be refreshed on a restart of shepherd, IIRC. Not great.
<rekado_>civodul: no objections to switching to pdftex. There are cases where we don’t actually build the documentation from source, and others where we don’t distribute the built documentation, so the impact there would be small.
<efraim>yeah, glib-networking. It'll take me a while to build out to it though on core-updates. I'll let you know if it's still failing for me
<rekado_>the generated files *should* be identical, but there have been *some* instances in the past where encoding problems messed things up.
<rekado_>so I guess we should just keep an eye on things.
<pineapples>I'm attempting to use the `superseded' property in my package definition but the build results in an error saying that I've used an invalid field specifier. Any idea what I may be doing wrong?
<maximed>pineapples: where are you putting 'superseded'?
<maximed>It seems like that property must be put in the 'properties' field
<pineapples>maximed: At the end of the definition, in the `properties' field
<munksgaard>Are there any packages that depend on using 8.6?
<munksgaard>I want to build a package (futhark) that depends on 8.8, but https://issues.guix.gnu.org/49326 is making life difficult for me. It would be easier (for me) to move the default to 8.8, which is two years old at this point.
<maximed>munksgaard: I wouldn't know. You can try moving GHC to 8.8, build random haskell packages and see what breaks.
<maximed>depending on the number of Haskell packages, this may be something for core-updates or staging
<munksgaard>maximed: There are quite a few haskell packages, I think :-/
<maximed>Maybe, after testing a few Haskell packages, ‘we’ could create a ‘ghc-update’ branch, and let 'ci.guix.gnu.org' build that branch?
<maximed>and when there are no haskell-related build failures there, and substitutes are available for everything, merge it?
<munksgaard>Sounds good to me. I'll try to get around to it later this evening.
<efraim>civodul: is posix_spawn buggy on all non-Intel systems or only on armhf and aarch64?
<pineapples>maximed: I am sorry for the late reply but I received an emergency call and had to leave my system for a while. Anyway, as I was going to say before I got interrupted, I will think about it but I can't promise anything; my writing style is—for the lack of better words—dull or/and "unimaginative", and the knowledge of Guix itself and its docs rather limited
<maximed>sneek: later tell civodul: Reintroducing %build-inputs when cross-compiling allows "guix build grep --target=aarch64-linux-gnu" to succeed on core-updates. Running the binary under "qemu-aarch64" works. I'll send a patch to guix-patches@
<PotentialUser-31>maximed: Oh, I didn't think to write chmod + x, thanks) Only now I have another problem, vpn started but I get "2021-07-05 18:35:09 WARNING: Failed running command (--up / - down): could not execute external program
<maximed>PotentialUser-31: what was the output of "ls -l /etc/openvpn/update-resolv.conf"?
<maximed>If it was /gnu/store/..., you shouln't chmod it. In fact, if you're on Guix System, the store should be unwritable even to root (unless root is playing tricks), so chmod +x /etc/openvpn/update-resolv.conf should fail if it is a symlink to a file in the store
<maximed>(If it isn't a file in the store, then "sudo chmod +x ..." is probably fine, but I'm not familiar with the openvpn service of guix)
<sneek>civodul, maximed says: Reintroducing %build-inputs when cross-compiling allows "guix build grep --target=aarch64-linux-gnu" to succeed on core-updates. Running the binary under "qemu-aarch64" works. I'll send a patch to guix-patches@
<apteryx>updating Guix from Feb 25 (a2ece4d): guix pull: error: Git error: failed to resolve path '/var/lib/jenkins/.cache/guix/checkouts/pjmkglp4t7znuugeurpurzikxq3tnlaywmisyr27shj7apsnalwq': No such file or directory
<efraim>raghavgururajan: glib-networking test is still failing for me on core-updates, 5/6 connection-gnutls TIMEOUT 30.03s killed by signal 15 SIGTERM, looks like timeout after ok 15 /tls/gnutls/connection/client-auth-request-none
<maximed>civodul: great, now I don't have to wait minutes for "guix environment glibc --ad-hoc email@example.com" to complete ... (I'm on a spinning disk and installing a package in a profile of 138 packages ...)
<civodul>apteryx: this issue was fixed by baf0a4288264098ede43e4f7cd099a29fcf35be4 (June)
<civodul>in the meantime, you can remove the cache
<maximed>maybe grafting and profile generation could be use multiple cores, processing separate files concurrently? That might help bringing the I/O to 100%
<maximed>I think I've a nice idea that should reduce grafting time a lot, at cost of package building taking longer
<maximed>Basically, don't scan for references & replace them. Instead, let each package output have a file, say, "reference-locations" containing a lists of file names and byte ranges where a store path can be found
<efraim>I've wondered about using bsdiff to create the replacement pckage when we have grafts
<maximed>so the grafting code could just copy everything that isn't a store path
<maximed>and maybe use fancy syscalls like "copy_file_range"
<boeg>what do i need to be able to require a package in emacs installed with guix package manager? I have added the load-path as well as called guix-emacs-autoload-packages, but the package i have installed is not autoloaded and i cannot require it
<maximed>boeg: in case of magit: "guix package -i emacs emacs-magit" should do it
<maxwell_TGAP>Is it possible to use the sticky bit on guix, if your not supposed to mess with the file attributes of anything in the /gnu/store then would you simply have to copy it out into ~/bin or something?
<apteryx>mmh, I'm a bit puzzled by "guix time-machine: error: could not authenticate commit 7f580c27daa5076f1961acabe4e6b4c7b17763c3: key ACC2 3BA0 59F7 CCF4 08F0 43AD 442A 84B8 C70E 2F87 is missing" when attempting to use 'guix time-machine --url=https://gitlab.com/Apteryks/guix.git --branch=add-deb-pack-format [...]'
<apteryx>the guix running the time-machine command was freshly updated
<civodul>apteryx: most like that repo's 'keyring' branch is lagging behind
<apteryx>did you source your profile etc/profile file?
<maximed>civodul: I wrote a message ‘TARGET-objcopy blabla’, and you wrote a message ‘maximed: i have a fix!’, so I assumed you had a fix for the ‘TARGET-objcopy bla-bla’
<maximed>Now I'm wondering what the fix you were talking about actually was ...
<Noisytoot>no. I am using fish, which can't source the profile (which is designed for bash). when I source it in bash, it works
<maximed>Noisytoot: (a) log out and in again, or (b) start bash, source the profile, start fish inside bash?
<Noisytoot>bash -c 'source "$GUIX_PROFILE/etc/profile"; exec fish' works when I install fish into my profile
<podiki[m]>maximed and munksgaard: regarding a ghc branch, would it make sense to make it a more general haskell updates branch? munksgaard and I have hit some bugs (and have some patches) that would affect haskell-build-system. given the number of affected packages for this change, that might be helpful. I'd want to update a lot of haskell packages too, but maybe that should wait
<maximed>Also, someone else would have to actually set up the branch, I'm no committer
<podiki[m]>I just mean when making changes and then needs build ghc, it takes a while
<podiki[m]>maximed: gotcha. I'll add a note on the patches/bugs that it would be best to set up a testing branch, and then I guess wait? (still very new here)
<maximed>podiki: In case I wasn't clear: one of the benefits of such a branch is that you can let ci.guix.gnu.org build things for you, and temporarily breaking things isn't a big problem (as long as things are fixed before it is merged in master, stating or core-updates)
<podiki[m]>maximed: yes, understood, that's why I was happy I won't have to rebuild everything. It is hot where I am, glad to save some cpu cycles and the free heat it provides
<efraim>15 gnulib tests failed on core-updates on findutils-boot0 on riscv64-linux
<iskarian>civodul, regarding your patch removing input labels: was there already a discussion about handling ("a.patch" ,(search-patch "a.patch")) in inputs?
***iskarian is now known as Guest8584
***cadmium.libera.chat sets mode: +o ChanServ
***iskarian is now known as Guest2833
<excalamus>I'm setting up the Emacs daemon following a thread on the mailing list: https://lists.gnu.org/archive/html/help-guix/2019-11/msg00148.html I have services.scm and init.scm defined. I can call `shepherd -c ~/.config/shepherd/init.scm` and the service starts. I can kill the terminal and connect a client with `emacsclient -c`. Trouble is, I can't figure out how to start the service on boot.
<drakonis>excalamus: declare it as a service on your system config
<drakonis>at least until guix home arrives and you can do it in a per user basis
<boeg>Anyone here installing emacs packages with guix package manager? I have added "(add-to-list 'load-path (expand-file-name "~/.guix-profile/share/emacs/site-lisp"))" to my init.el and call `guix-emacs-autoload-packages` but it doesnt work, i have to point directory to a package directory to make it work like this: "(add-to-list 'load-path (expand-file-name "~/.guix-profile/share/emacs/site-lisp/magit-xxxxxx"))" and hten it works, but it
<boeg>cannot be right that I have to do that for all packages? It looks to me as if `guix-emacs-autoload-packages` isn't doing its job to find all the packages in the directory. Maybe I am doing something wrong?
<maximed>boeg: What happens if you delete .emacs and ~/.config/emacs?
<boeg>so ... as I understand guix-emacs-autoload-packages, it should look at the load-path and find the path with the guix package manager packages and add each packages path to the load path so it can be loaded, right?
<maximed>boeg: I think so? But it should be run automatically, you shouldn't need to add it anywhere ...
<boeg>i usually only use `guix install` for things until i am sure they are "staying", then i move them to my config.scm
<maximed>If you prefer declarative "config.scm"-like things above imperative "guix install"-like things, you might be interested in manifests and guix home-manager
<boeg>i do - can you give me a link to the former, i think ill be able to search out the latter
<maximed>manifests are like the 'packages' field of 'operating-system', but for user profiles
<excalamus>drakonis: I'm a bit confused about how I would add the service to my system config, or rather, how that would work. Would you suggest defining the service directly in the system config file? Or instead call (load "...") on the .config/shepherd/init.scm? I find both confusing because I expect Shepherd to automatically search some dirs. In fact, the third paragraph of (shepherd) Jump Start shows just that, /etc/shepherd.scm and
<excalamus>$HOME/.config/shepherd/init.scm should be searched on start. The latter is searched when Shepherd is started as a normal user, so I suppose that explains why my current setup doesn't work. I assume that Shepherd is started at boot by a superuser. Anyway, if I throw my user-made emacsd in (services (append (list ...))), how would the system know about it?
<maximed>boeg: see --export-manifest in the manual and --manifest
<ixmpp>i have since switched to zsh, but that's not because it's better or anything
<ixmpp>i just had a very specific issue that seems less prevalant with zsh
<The_tubular>Anyone tried to run guix on arm devices like a rasberrypi ?
<munksgaard>podiki: It looks like that will just reply to you directly. I'll figure it out.
<podiki[m]>munksgaard: I guess that and have a cc: firstname.lastname@example.org? also not sure, generally I just read the lists so it is new to me too
<bmk>Okay: I may have fecked somethin' up here: Am I able to have GRUB not be encrypted (so grub can run without needing to unlock the / and /home partitions), and if so what would that look like in my system declaration
<bmk>I just realized I have no swap partition either: I'm gonna need a reinstall anyways