<nckx>null_radix[m]: I'm not proud of that command but it'll do 😉
<null_radix[m]>im sill curois how this works, just digging into (gnu services base), tbh i had not heard of EUDEV, and was confused becuase `man udev` seems to suggest the locations for rules are fixed
<vagrantc>nckx: i don't think i knew the existance of check-system before
<nckx>It's probably not relevant for you (unless Debian has some strict every-upstream-test-suite-must-pass policy), since ‘check’ should suffice to test Guix the package manager.
<vagrantc>nckx: well, it's relevent for me, in that i mostly run Guix System, i guess :)
<nckx>It would be relevant if someone uses Debian's Guix to ‘guix system init’ something, but I don't know if that's common.
<nckx>vagrantc: Oh, I thought this was in the context of packaging, never mind 🙂
<vagrantc>by the time the debian packages were mature enough to actually use ... i'm pretty much a fan of guix :)
<dissoc3>i have guix running with stumpwm. Im trying to configure multiple monitors but if I run arandr/xrandr it closes and brings me back to gdm. is there something I should be doing with gdm to configure monitor layouts?
<plasma41>For example, according to https://lists.gnu.org/archive/html/info-guix/2018-12/msg00000.html the final documentation and manpages in the distribution source tarballs were generated with Makeinfo 6.5 and Help2man 1.47.8 and the configure and Makefile.in files were generated with Autoconf 2.69 and Automake 1.16.1. I'd like to know what versions of those programmed were used for each of the 1.0.0, 1.0.1, and 1.1.0 releases.
<jgarte>Blackbeard: thanks for the link. I've gone through ambrevar's packaging tutorial so far
<lfam>plasma41: You probably won't get an answer here tonight because it's very late at night for the person who did the release
<apteryx>I started gpg-agent with: 'gpg-agent --debug-pinentry --debug 1024 --server', but it's dead quite when issuing 'echo test | gpg --clear-sign'. That later command prints: gpg: signing failed: No pinentry
<jgarte>Blackbeard: yes, it appends git to the current environment? Wasn't sure which of my questions you were saying yes to
<Blackbeard>jgarte: I am pretty sure it is the same. But I am not 100% sure
<lfam>I can't tell from the upstream bug discussion if the underlying problem is that gnupg is actually failing to find pinentry, or if that error message is incorrect. You could use strace to find out
<Blackbeard>Sorry matrix lags and you asked the second question before my message went out
<lfam>Blackbeard, jgarte: When using --pure, every time you do `guix environment` it starts from scratch
<jgarte>Blackbeard: no worries just trying to clarify
<apteryx>there are two things which I did which might have led to this: 1) stow a version config of my .gnupg directory (it creates symlinks of configs such as gpg-agent.conf to a git versioned directory). or 2) update my profile and system to latest Guix.
<jgarte>Blackbeard: thanks for all the help thus far
<dissoc3>Blackbeard: so i have 7 monitors. right now im just trying to get 4 to work with one video card (nvidia 960) using stumpwm. stump loads and 4 monitors work but they are not arranged how I want. So i tried using arandr and every time i try to apply the new arrangement it logs me out and takes me back to gdm.
<jgarte>If someone follows the video tutorials they will get to the part that says to make a branch and be stuck without git in the development environment
<dissoc3>Blackbeard: i also tried to write a xorg.conf file but then gdm wouldnt even load
<jgarte>Should the guix environment command in the video tutorial be updated to mention to install git?
<lfam>jgarte: You only need to be in the development environment while building Guix. You can leave it while writing code and using Git
<jgarte>@3:16 of packaging tutorial video (part two)
<lfam>For example, I am rarely spending much time in the development environment. Only when I am done writing some code and want to test it do I enter the environment
<lfam>Another way to handle this would be to use two terminal windows, one for coding and version control, the other for building Guix
<jgarte>lfam: Ohh ok. I didn't realize that. I was trying to do coding and building in the development environment
<apteryx>lfam: ah, got it. After using GNU Stow to deploy my versioned '.gnupg' config, some SSH keys were missing from under ~/.gnupg/private-keys-v1.d. I could reimport them in my private keyring using 'ssh-add path/to/ssh-key', and encrypting it with a passphrase.
<apteryx>raghav-gururajan: I've merged the remaining cosmetic patch and closed the linphone tracker. Congrats!
<ecbrown>i used the importer to great effect, e.g. r-brms
<dhanvanthri>Hey guys, I'm just trying to get cdda with tiles working straight from the binary, I'm using pkill9's fhs service, and I basically just stole the relevant parts of their config from their the gitlab page. I'm getting the following error, and I have NO idea how to diagnost/solve this problem
<dhanvanthri>\guix system: error: getting status of /gnu/store/.links/026z1vrprv88zrwg5qp5ak0z5dfg2ig2syq306ib8w7snc90kggw: Bad message
<apteryx>For example, we can't visit the preferences menu without it crashing. The round, orange button on the top right also trigger a crash, mentioning the lack of QuickDialogs. It seems it needs a couple more Qt QML (unpackaged) dependencies
<rekado_>I hope we’ll have enough space for all of debbugs. Would make it easier to develop missing debbugs features in mumi.
<civodul>oh right, all of debbugs can take quite some space
<rekado_>civodul: links-traversal is *slow* on ci.guix.gnu.org :-/
<civodul>perhaps we should store it on a squashfs?
<rekado_>the first run (without dropped caches) in mode 3 took 67 minutes.
<lprndn>I was trying to build a custom kernel for an ARM board. Getting errors. Just found that the problem was that the git-checkout/include was added to CPATH creating conflicts. My question is why did it happen..?
<janneke>grmbl, python-boot0 needs a similar change to python-2.7, but not to python which is python-3.8, because build system changes between 3.5.9 and 3.8.2 ... /me goes to check git to make a proper comment and fix
<raghavgururajan>apteryx We just need to add 'qtquickcontrols' as input, along with 'qtquickcontrols2'.
<mbakke>ooh, substitute coverage on core-updates for x86_64 is now at >= 83.4%
<mbakke>at this rate it will still take weeks before armhf and aarch64 catches up though
<allana>Hi Guix. Anyone else having issues running "guix pull"? I have not been able to for the past couple of days. Could it be releated to the new release? I'm getting the error "failed to produce output path '/gnu/store/blahblah-guix-package-cache'"
<mbakke>allana: are you using any custom channels?
<rekado_>hmm, I get “implicit declaration of function �statx�;”
<bricewge>rushsteve1 Did you tried the last command lfam suggested you?
<lfam>Changing to subject to icon themes, what's the current consensus on whether or not they should be hard dependencies? Previously, we expected users to install them, but I notice that a lot of packages are using them as inputs now
<raghavgururajan>apteryx, That's correct. I have made it to build it sucessfully on master by using gcc-5.
<apteryx>raghavgururajan: But that's nothing new (2018). So the original problem building linphoneqt must have been with Qt, correct?
<raghavgururajan>apteryx That's correct. But if one declares ("gcc" ,gcc-5) as native-input, build-system uses gcc-5 instead of gcc-7.
<bricewge>rushsteve1: Hum that should have worked. Can you share the exact command line you are using that generate the error?
<apteryx>I'm not sure that'd be reliable without filtering out the gcc7 stuff that comes with in the implicit inputs. Danny had commented about this, and chose core-updates because there it works without doing anything special. I think we should leave it there, until the next core-updates merge.
<apteryx>mbakke: when was core-updates last merged into master? I fail to find this information in the git log.
<lfam>rushsteve1: From within the environment, please run `env` and share the results of <https://paste.debian.net>. You may need to also add coreutils to the environment in order to get the `env` command
<lfam>rushsteve1: Also, you could poke around in the profile pointed to by GUILE_LOAD_PATH in that `env` output, and see if it contains the Guile gcrypt module
*ecbrown had forgotten what a beast guile-emacs is to compile
<roptat>looks like I was able to free quite a bit of space, and texlive was preserved, so thank you!
<lfam>rushsteve1: After building the fresh Git checkout using the same Guix as you, I can do `./pre-inst-env guix build hello`, if I am in the `guix environment --pure guix --ad-hoc guile-gcrypt` environment. And that is having guile-gcrypt from my normal profile