IRC channel logs


back to list of logs

<nckx>OK, so that definitely does not depend on unprivileged user ns'es.
<nckx>I get an ‘obvious bug’-bug when making check-system, did you encounter this vagrantc?
<Blackbeard>nckx: thanks
<null_radix[m]>thanks nckx! that looks a lot better
<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 :)
<vagrantc>nckx: well, yes, context matters
<nckx>Don't it just.
<vagrantc>one of the use-cases i wanted a debian package for was to be able to install it and use "guix system init" on, say, armhf or arm64 systems
<vagrantc>never much liked the installer script, so i always installed the guix binary stuff by hand ... but a debian package would give a starting point that's easier for me to work with
<vagrantc>hmm... gdisk isn't packaged for guix ...
<nckx>I've always done the sam.
<nckx>vagrantc: It is, the project & package name is gptfdisk.
<Blackbeard>nckx: hey, is it ok if I pm you?
<vagrantc>nckx: oh!
<nckx>Blackbeard: OK.
<nckx>Thanks for asking.
<vagrantc>are partition uuid's supported in file-system definitions?
<nckx>The GPT ones? No, since they're not part of a file system (and just generally not supported at this time).
<nckx>Use file system UUIDs.
<jgarte>Hi! Is there something like this built into guix?
<jgarte>I know guix has this:
<Blackbeard>jgarte: there is 'guix deploy' too
<plasma41>So I see that guix 1.1.0 is out (congratulations by the way), but I haven't seen an announcement email on the info-guix mailing list.
<Blackbeard>and you can create tarballs with 'guix pack'
<Blackbeard>but I am not sure if those are exactly related to what you are looking for
<lfam>I forgot about the info-guix ML
<nckx>To be quite honest, I think the existence info-guix was simply forgotten.
<nckx>Me too.
<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>The release announcement for guix 0.16.0 ( listed what versions of the autotools were used to bootstrap the distribution source tarball. Non of the release announcement for releases since then have contained this information. What versions of the autotools bootstrapped the 1.0.0, 1.0.1, 1.1.0 releases?
<plasma41>s/Non of the release announcement/None of the release announcements/
<jgarte>Blackbeard: thanks! I am interested knowing what the current state of packaging node/npm javascript packages in guix is? Is there a best practice?
<vagrantc>the bootstrap set has been massively reduced
<jgarte>I just read this too
<vagrantc>plasma41: so i'm not sure there is any autotools used in the bootstrap
<Blackbeard>dissoc3: I use StumpWM without trouble
<nckx>plasma41: 2.69. Note that Guix uses its ‘own’ packages for that too, not whatever random autotools happened to be on the releasers machine at the time.
<Blackbeard>dissoc3: what do you want to do ? Can I see the xrandr command?
<jgarte>I want to package this:
<plasma41>Different bootstrap. I'm asking about the versions of the autotools used to create the configure and other generated files in the source tarball.
<Blackbeard>jgarte: I've not packaged anything from npm. But I can try to help you if you wanna try to package
<jgarte>Yes, I'd love to help out with packaging
<jgarte>I have a bucketlist of packages I would like to package
<jgarte>I'm trying to wrap my head around the node build system in /guix/build-system/node.scm
<Blackbeard>jgarte: have you installed guix already?
<jgarte>Blackbeard: yes
<jgarte>I installed the binary on arch linux
<Blackbeard>jgarte: have you cloned the repo?
<nckx>plasma41: Why would I not understand that? So am I.
<jgarte>Blackbeard: I'm doing that now
<Blackbeard>jgarte: the videos are really nice, if you want to give them a look
<plasma41>For example, according to 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 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
<lfam>plasma41: You can ask again during the European day or, even better, reply to this message about the subject:
<lfam>I'm not sure but I'd expect it to be the programs provided in Guix at the time / commit of the release
<nckx>plasma41: The versions of those packages in Guix. autoconf 2.69, help2man 1.47.13, automake 1.16.2.
<nckx>I cannot make this much clearer.
<nckx>Check out (or pull) Guix 1.1.0, look at the versions of the packages you are interested in.
<nckx>You can verify this by looking at the 1.1.0 sourceball if you don't trust random nckxes on the Internet.
<nckx>As well you shouldn't.
<plasma41>nckx: Would it be the tagged git commit or the one immediately prior? Which describes the state of the machine actually creating the tarballs?
<reepca>hmm, python-jedi fails to build due to a test failure
<vagrantc>ok, successfully booted guix on rockpro64-rk3399 ... though there are issues with linux-libre-arm64-generic and missing cgroup features used by elogind...
<lfam>plasma41: You should check the 'release' target of to see exactly how it works
<Blackbeard>jgarte: have you set up everything ?
<jgarte>Blackbeard: Just watching the videos now. They are great! I'm at part one of packaging
<jgarte>nnn is out of date. I would like to update that
<jgarte>current version is 3.1
<Blackbeard>jgarte: that shouldn't be hard. It seems like it is a good way to stact
<jgarte>nnn is up to date in nixpkgs so I would like guix to be the same
<Blackbeard>jgarte: wonderful. Watch the videos and let me know if you need any help.
<jgarte>Blackbeard: I'll be right back. Almost done watching them.
<dustyweb>congrats on 1.1.0!
<jgarte>Blackbeard: All most set up. waiting for "make" to finish
<jgarte>Blackbeard: Almost set up. waiting for "make" to finish
<Blackbeard>jgarte: wonderful :)
<jgarte>Blackbeard: still compiling .go files in /gnu/packages/ (%68 done)
<Blackbeard>jgarte: no worries, have you looked the definition of nnn already?
<jgarte>I have not edited it yet
<Blackbeard>jgarte: check this one too if you have not already
<Blackbeard>it is similar to the tutorial on the guix blog
<jgarte>Blackbeard: hmmm 404 error not found
<jgarte>for the above cookbook link
<Blackbeard>jgarte try this one
<jgarte>Blackbeard: I found an alternate link
<jgarte>thanks yours works too
<jgarte>Blackbeard: at 86% (I have an old Thinkpad T400 :)
<Blackbeard>jgarte: that's alright, why don't you start by copying the definition of nnn in an empty file
<jgarte>ok will start with that now
<Blackbeard>jgarte: have you read the cookbook on the tutorial in the blog?
<lfam>Looks like ISC's versioning scheme has changed since the last time I paid attention
<jgarte>Blackbeard: Yes, but I have not assimilated it all yet
<lfam>Maybe we can remove 'bind-release-type' and 'bind-release-version' from the isc-dhcp package
<Blackbeard>jgarte: don't worry we will get there
<jgarte>Blackbeard: Ok, I've edited the nnn package and changed the version to 3.1 in the definition
<jgarte>trying to download the base32 sha to paste it in now
<jgarte>Blackbeard: should I get that from here
<Blackbeard>jgarte: please past your definition here
<jgarte>the base32 is incorrect in that definition
<Blackbeard>jgarte: I know, don't worry
<jgarte>Blackbeard: Ok :)
<jgarte>unfortunately (or fortunately I did the whole process thus far in eshell) and my original user environment variables are not setup in the dev environment for emacs
<jgarte>so dired or find-file does not work in the dev environment
<jgarte>I just opened a shell outside the environment to do the editing/pasting/etc...
<Blackbeard>It is ok. So far I had not been using the tar file but the hash and used git-fetch
<Blackbeard>jgarte: I am not sure which one is preferred, but I like git-fetch more
<jgarte>Should I change the nnn package definition to use git-fetch instead of url-fetch?
<Blackbeard>jgarte: what was the original definition using?
<Blackbeard>jgarte: keep it as it was
<jgarte>Blackbeard: My guix environment cannot find git even with ./pre-inst-env I'm trying to create a git branch
<jgarte>Blackbeard: I can setup a git branch outside of the guix environment but inside the environment the git binary is not available
<jgarte>Blackbeard: $ ./pre-inst-env git checkout -b nnn-update./pre-inst-env: line 62: exec: git: not found
<ecbrown>guix environment guix --ad-hoc git strace texinfo
<Blackbeard>jgarte: wait, can you paste your definition please ?
<jgarte>ecbrown: thanks ecbrown. Once I have built the environment with "guix environment --ad-hoc" can I add packages that I forgot to add via "guix package -i" ?
<jgarte>In others words what is the correct way to "append" packages to an environment after its' creation?
<apteryx>about gpg failing to find a pinentry (even when we specify one), it seems to be a current open bug:
<apteryx>well, I'm not sure in the end. It seems to affect a mix of GnuPG from master (to become 2.3) and 2.2, rather than say, 2.2 only. Not sure.
<Blackbeard>jgarte: ok is it working now?
<lfam>apteryx: I think it should be working "out of the box" on Guix since commit e5b44b06b3fb19c897fb3e430bd41941905e101f
<lfam>apteryx: Are there more reports of problems?
<lfam>Or is this some other problem?
<Blackbeard>lfam: where can I add icons or cursor themes?
<lfam>Blackbeard: It's recommended to install adwaita-icon-theme or hicolor-icon-theme, or maybe some other one
<Blackbeard>lfam: but as a package if I want to add a cursor theme
<lfam>Like, you want to package a new cursor theme?
<apteryx>lfam: Not yet more reports of problems, no. I'm stuggling to debug this.
<jgarte>Blackbeard: git is not working in the environment so I cannot create a branch in it. Should I run "guix package -i git" to add it to the environment?
<lfam>Blackbeard: Hm... not sure! Where are adwaita-icon-theme and hicolor-icon-theme?
<Blackbeard>jgarte: use git without the ./pre-Inst-env
<lfam>apteryx: It looks... confusing
<Blackbeard>Just inside the [envió]
<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
<Blackbeard>Sorry [env]
<apteryx>dead quiet*
<apteryx>s/That later command/The later command/
<lfam>And you have a pinentry package installed, apteryx?
<apteryx>yes. The 'pinentry' named package.
<jgarte>Blackbeard: git is not found in the environment that I set up with "guix environment". With or without ./pre-inst-env
<Blackbeard>lfam: adwaita is in gnome.scm
<jgarte>I definitely have git installed on my machine it just can't be found once I run "guix environment"
<Blackbeard>jgarte: $ exit
<lfam>jgarte: That's expected jgarte. `guix environment` works by changing environment variables such as $PATH, which is how your shell finds programs like git
<Blackbeard>$ guix environment guix --pure --ad-hoc git
<Blackbeard>$ which git
<lfam>Blackbeard: It's up to you where to put it. Whatever makes sense to you
<Blackbeard>lfam: and xcursor-themes are on xorg.scm
<Blackbeard>arc-theme and arc-icon-theme are on too
<Blackbeard>I wonder if there should be a module eye-candy.scm hahahha
<jgarte>Blackbeard: does the above command append git to the environment I already created?
<jgarte>Blackbeard: or does it create a whole new environment?
<Blackbeard>Or maybe just themes.scm
<apteryx>lfam: but I've tried ruling out the new patch to auto-find pinentry, by installing the older version 2.2.19. It didn't solve the issue, sadly.
<Blackbeard>jgarte: yes.
<apteryx>so I think this is ruled out.
<lfam>apteryx: It sounds like you need to pass --yes, which is an amazing option
<apteryx>didn't help... Hm.
<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
<Blackbeard>lfam: ah ! I did know that. Thanks
<jgarte>lfam: thanks for the info. That's good to know.
<lfam>It's fun to run `env` after `guix environment ...` to see what it does
<apteryx>I vaguely remember GnuPG not liking symlinks in the past, perhaps i should get this out of the equation as a start.
<Blackbeard>Ok let me try that
<Blackbeard>lfam: you know basically everything
<lfam>You might need to add it to a --pure environment with '--ad-hoc coreutils'
<lfam>Lol no
<lfam>Just more
<lfam>Eventually you will know these things too
<dissoc3>Blackbeard: sorry for delay. you asked what xrandr command i was running. I was just using what was generated by arandr
<lfam>`guix environment` used to work in a more transparent way, because it would make PATH variables like PATH=/gnu/store/...-curl:/gnu/store/...-gnutls:/gnu/store/...-bash
<lfam>But now it creates a profile and makes that your PATH, so you don't see all the store items unless you look into the profile
<lfam>But, it's still easy to poke around
<dissoc3>i tried to write an xorg.conf file and shove it in (extra-config ...) but that didnt work. would that even work?
<pkill9>it should work, that's it's purpose
<jgarte>lfam: so running guix environment without --pure will append packages to the current environment and profile?
<lfam>Yes jgarte
<jgarte>lfam: thanks! trying it now :)
<Blackbeard>dissoc3: ok lets go from the start. What do you want to do?
<Blackbeard>jgarte: you should use --pure for guix patches !
<lfam>Yes, --pure is the way to go in most cases
<jgarte>So should I just build the whole environment over again and include git this time?
<Blackbeard>Because you want to make sure they build
<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
<jgarte>lfam: thanks for that tip!
<lfam>You're welcome!
<apteryx>lfam: I logged out... Back in... And, bam, pinentry works.
<jgarte>lfam: that's very helpful information to know
*apteryx wasted 2 hours on nothing
<lfam>That's so annoying
<apteryx>haha! Yes, there was probably some stale environment variable captured at my previous login, that caused an issue after reconfiguring my profile.
<lfam>There are three hard problems in computer science: Naming things, cache invalidation, off-by-one errors, and environment variables
<jgarte>:lfam how can I test that I am in the development environment
<jgarte>:lfam is there a quick way/trick to know?
<jgarte>I've closed and opened so many terminals now that I am not sure I am still in it
<Blackbeard>dissoc3: what happens if you run xrandr commands inside a shell
<Blackbeard>dissoc3: I have this inside my .stumpwmrc
<Blackbeard>(run-shell-command "xrandr --output HDMI-1 --mode 1360x768")
<dissoc3>Blackbeard: good idea. i will try that
<Blackbeard>jgarte: I use the videos, I never had a problem with git :/ I don't know why you are having this problem
<Blackbeard>jgarte: I recommend using emacs-magit, but that is just a preference hahaha
<jgarte>Blackbeard: I think it is because I was trying to use git inside the container and the environment variables where not setup for it
<jgarte>See :lfam reply to me above
<Blackbeard>jgarte: yes I saw it but I never had trouble to run git inside the [env] without the ./pre-Inst-env
<jgarte>Is there something like this built into guix to let you know if your current terminal is in a guix environment or not?
<jgarte>Blackbeard: maybe it has something to do with eshell (I am using emacs' eshell to follow the tutorial)
<dissoc3>Blackbeard: from the terminal the same outcome.
<jgarte>I would have used zsh or something else but I didn't realize it until the whole environment was setup and didn't want to start over again
<apteryx>do we do something about embedded fonts in Qt applications?
<apteryx>linphoneqt embeds Noto Sans
<Blackbeard>jgarte: don't worry about it too much for now. Just make sure everything works
<jgarte>I think I've answered my above question: ls "$GUIX_ENVIRONMENT/bin"
<Blackbeard>dissoc3: it logged you out?
<Blackbeard>dissoc3: what are you running ?
<dissoc3>Blackbeard: gdm
<dissoc3>Blackbeard: I tried to use slim but I failed at that
<Blackbeard>jgarte: my eshell line changes color when inside an env
<dissoc3>Blackbeard: initially I just wanted to run startx but for whatever reason that seems really hard?
<Blackbeard>dissoc3: what command sorry
<jgarte>Blackbeard: hmmm I think mine is not setup to do that. Will look into it. Thanks!
<Blackbeard>jgarte: mine is vanilla eshell. No config
<Blackbeard>jgarte: but did you succeeded at building the package ? Or is it still running ,
<jgarte>I just started it it now with guix package -i nnn
<jgarte>after I edited admin.scm
<jgarte>where the nnn package definition lives
<jgarte>I got this error:
<jgarte>But it says that it will install nnn 3.1 so I guess that is good news
<jgarte>Just waiting for the compilation process to finish
<Blackbeard>jgarte: no don't do that
<jgarte>hmmm ok
<Blackbeard>Use ./pre-Inst-env guix build package
<jgarte>stopped it
<Blackbeard>jgarte: did you watch the third build video?
<apteryx>wow, google-font-noto weighs 736 MiB
<sirgazil>I just pulled, reconfigured the system with my GNOME + GDM configuration, and GDM doesn't start.
<Blackbeard>dissoc3: but what is the xrandr command you ran?
<sirgazil>I see "New session c1 of user gdm", then some other messages, and then "Removed session c1"
<jgarte>Blackbeard I get this now with the command you suggested:
<jgarte>Is my environment not pure any longer because I ran the prior command?
<jgarte>Blackbeard: I did watch the third video but I forgot that detail. Sorry
<jgarte>I'm going to review it now
<sirgazil>I continue to have a bad experience with Guix releases :(
<bavier`>sirgazil: I've had issues with gdm failing to start in the past
<bavier`>I seem to have fixed it, lemme see if I can remember how
<Blackbeard>jgarte: I wrote down everything in the videos so I can easily follow what I have to do next
<jgarte>Blackbeard: I should have done that. I will make an ordered list for myself. Thank you!
***calher is now known as KE0VVT
<bavier`>sirgazil: sorry, I'm not sure exactly what "fixed" that issue for me; I did recently remove the "spice-vdagent-service"
<Blackbeard>lfam: do you know if there had been any work on packaging searx
<lfam>Yes, check messages from January and February 2017 on guix-devel
<sirgazil>bavier`: I don't have that service in my configuration. Thanks for taking a look anyways.
<jgarte>Blackbeard: I will try packaging nnn tomorrow again and will report here if I run into any issues after running through the steps of the tutorial. Thanks for all your help.
<Blackbeard>lfam: thansk!
<Blackbeard>jgarte: what happened?
<Blackbeard>Veera: hi!
<sirgazil>in "/var/log/debug" I see "Apr 15 22:39:14 localhost gdm: Child process -538 was already dead."
<Veera>Blackbeard: Hi
<Veera>sirgazil: filed a bug report #40652
<Veera>sirgazil: happened to me since april 11
<guix-vits>Hi there.
<sneek>Welcome back guix-vits, you have 1 message!
<sneek>guix-vits, nckx says: I see I sent it too late ☹ Sorry 'bout that; mail troubles. (Client, not server, the actual mails are safe.)
<sirgazil>Veera: Bah, thanks.
<Veera>sirgazil: what to do?
<Veera>guix-vits: Hi
<Veera>sirgazil: Is there anyway to debug gdm atleast gdm logs; I can't enable the debug option!
<sirgazil>Veera: I don't know.
<Veera>sirgazil: I can't trace where and when the change happened. Git log does not says much.
<apteryx>lfam: ah! now I get my pinentry for GPG keys access, but not for SSH keys access (I use 'enable-ssh-support' in my gpg-agent.conf).
<apteryx>at least through git
<Blackbeard>hi guix-vits !!
<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!
<apteryx>raghav-gururajan: seems we're missing this package:
<apteryx>linphone crashes when trying to click on the orange top right icon with the error: qrc:/ui/modules/Common/Form/DroppableTextArea.qml:3:1: module "QtQuick.Dialogs" is not installed
*apteryx zzzz
<Veera>Hey Why are not replies to my submitted bug#40652 are coming to my mailbox?
<rekado_>Veera: did you use the web interface?
<rekado_>I saw an email queued up there, but it didn’t get through
<rekado_>I have a few appointments today, but will check on this later
<Veera>rekado_: no plain smtp mail
<rekado_>then I don’t know
<Veera>rekado_: where is the web interface?
<rekado_>it’s at but it’s currently in read-only mode and frozen to address a problem.
<Veera>rekado_: this I know!
<rekado_>hmm, cuirass is kinda slow, even when running it locally.
<rekado_>some database queries take 17+ seconds.
<rekado_>this explains why the pagination is configured to have only 10 items per page.
<rekado_>at 10 items it 3 seconds
<rekado_>at 30 it rises to 17s
<rekado_>heh, the index on the builds table has been lost
<rekado_>no wonder
<civodul>Hello Guix!
<janneke>hello civodul!
<efraim>hello everyone!
<starcrATI>Hi Guix o7
<janneke>hello efraim
<bricewge>Hello Guix
<starcrATI>While trying to reconfigure my system, the build for etc.drv failed ... the log says ERROR: In procedure symlink: File exists
<starcrATI>Any ideas ? :)
<bricewge>starcrATI: Can you share the complete log and your config on ?
<lprndn>hello guix!
***apteryx is now known as Guest40532
***apteryx_ is now known as apteryx
<dftxbs3e>civodul, yay release! :-) - hope to resume work on powerpc64[le] soon.. I work at an hospital and with the crisis my time is 100% there.
<bricewge>Hey dftxbs3e, hope you are doing okay on the front-line
<dftxbs3e>bricewge, I'm only in a computing department so I'm OK :-)
<dftxbs3e>and I work from home (!)
<bricewge>Nice to hear, it's for sure way safer
<starcrATI[m]>liberdiko: I did :)
<bricewge>starcrATI: I had a look and I have no idea where it can come from, sorry
<bricewge>The error message is really terse
<civodul>hey dftxbs3e, good luck with your work!
<starcrATI[m]>liberdiko: huh, thank you anyways!
<bricewge>starcrATI: Can it be rottlog-service-type?
<bricewge>It has been added to %base-services, try removing it maybe it's duplicated.
<starcrATI[m]>Okay, I'll try
<starcrATI[m]>liberdiko: That was it! It worked now, thank you :D
<raghav-gururajan>apteryx Thank you!
<rekado_>hmm, “guix gc” is very slow on
<rekado_>it spends a lot of time trying to delete unused links
<rekado_>maybe at the size of the store on deduplication at the disk level would be better
<sirmacik>hey guix!
<sirmacik>congrats on new release (:
<sirmacik>just put my old ssd back and upgrading
<sirmacik>btw. anybody used inotify from guile? ;x
<civodul>rekado_: "deleting unused links" has always been slow :-/
<civodul>rekado_: do you see anything to add to ?
<civodul>bioinfo, etc.
<rekado_>civodul: the draft looks good to me. I don’t really have any bioinfo news other than the mentioned R packages.
<civodul>ok, thanks for taking a look!
<civodul>oh wait, i can add GWL under "Packages"
<rekado_>oh, good idea
<rekado_>(even though I haven’t been able to even look at the GWL since going back to work)
<ecbrown>i'm a big R user, and notice that there are many r-* pacakges. i guess my question is, should i bother "flooding" guix with contributions from the many of 10,000+ packages of cran?
<rekado_>Why Is Time?
<ecbrown>(sorry for interupting current convo)
<rekado_>ecbrown: flooding is welcome!
<rekado_>ecbrown: I have a Guile script for mass imports
<ecbrown>rekado_: i'm willing to help, just wonder there are numerous packages where i suspect libs from guix proper are needed
<ecbrown>e.g. gdal
<rekado_>the big problems with R packages are that the declared inputs on CRAN are sometimes bogus and that the descriptions often need a bit of work.
<rekado_>we have r-rgdal
<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
<dhanvanthri>This is when trying to do sudo guix system reconfigure btw
<civodul>"Bad message"?
<ecbrown>rekado_: oh, yes, i mean, was referring to occasions where r package install will give: "you need to install such and suchf rom apt/yum"
<rekado_>ecbrown: I guess we should coordinate our efforts, e.g. by bringing the discussion to
<dhanvanthri>civodul: That's the literal paste that I get back as an error
<ecbrown>no problem. oh, thanks for r-tidyverse. saves a world of headache. and rstan
<rekado_>ecbrown: yeah, in those cases it’s just a matter of figuring out what library is needed.
<dhanvanthri>civodul: Btw, tyvm ludo. This is an amazing piece of software.
<ecbrown>cool, thx
<rekado_>ecbrown: I had some WIP for ROOT, but it’s very difficult
<ecbrown>that would be huge
<rekado_>so not all R packages can easily be added, but most of them are not that difficult
<rekado_>some CRAN and Bioconductor packages have non-free licenses, which is a big problem.
<ecbrown>ok, so i will plan to edit them in emacs and lint them
<rekado_>especially for the CRAN packages the licenses are sometimes unclear because the code was ported from S.
<rekado_>when you have a bunch of packages that you want to claim please announce this on (and put me in Cc)
<rekado_>this way we can avoid stepping on each others toes
<civodul>EBADMSG, didn't know that
<civodul>dhanvanthri: is that on NFS or something?
<dhanvanthri>civodul: What is NFS? If that's a filesystem, this is just ext4
<civodul>ah ok (NFS is a "network file system")
<civodul>then i don't see how stat(2) can return EBADMSG
<rekado_>dhanvanthri: NFS is Network File System; it’s used when you mount a remote file system (from an NFS server) on your local system.
<rekado_>civodul: re — now that we have a very big store with I can run the links-traversal thing again.
<rekado_>will send my results later
<rekado_>we have 600+ million inodes in /gnu on
<rekado_>130+ million IUsed
<dhanvanthri>civodul: Yeah, I only have a single thing mounted, and it's my whole filesystem and it's local and ext4
<dhanvanthri>I'm just gonna restart and see if that helps
<rekado_>oops, “main: Assertion `count < MAX_ENTRIES' failed.”
*rekado_ increases MAX_ENTRIES
<efraim>I feel like I'd have less machine-usage conflicts and fewer gc sessions if I work on the ppc bootstrap from an aarch64 board ...
<Veera>Hi guix
<cetjs2>How to install java to guixsd?
<ecbrown>guix package -i icedtea works for me
<cetjs2>ecbrown, jdk
<ecbrown>if i type: guix environment icedtea -- javac -version
<ecbrown>i get the javac compiler version.
<ecbrown>i.e. i think jdk and docs are there
<efraim>wouldn't it be 'guix environment --ad-hoc icedtea:jdk -- javac -version'
<ecbrown>oops yes
<efraim>or whatever the later versions of java are called instaed of icedtea
<rekado_>for later versions use the openjdk package
<efraim>i knew it wasn't called java, couldn't remember the actual name though
<efraim>the static guile I copied to my ppc box worked, so now to actually update the guix tree there and try building
<kraai>When I try to add a calendar in GNOME Calendar, it crashes. When I try to debug it with gdb, it doesn't look like there's any debug information. How can I get debug information?
<civodul>rekado_: the "Rockerverse", Docker images for R:
*ecbrown just rolled a docker + restrserve
<ecbrown>(with a bunch of other stuff to predict out of h2o)
<ecbrown>making these docker images like cookies, up arrow edit return
<civodul>ecbrown: who well would "guix pack" suit your needs?
<civodul>*how well
<ecbrown>i am using that now, guix pack -f docker -C none ...
<ecbrown>then load that docker file any darned place
<ecbrown>i'm going to set up a battery of these behind nginx
<ecbrown>it's kind of sick what you can do with a 64-core threadripper :-)
<ecbrown>also just runs in a container, or any other abstraction. but glad to have this in guix cuz it gives options
<civodul>cool, i thought you were using a Dockerfile or something
<civodul> is blank
<civodul>the 2nd comment at is weird
<civodul>"the default channel requires some github account setup" ?!
<civodul>someone with a Reddit account should reply
<ecbrown>"no it doesn't" lol
<efraim>I responded a few hours ago and I found their thread on help-guix. I don't feel like the two mesh at all
<efraim>I figured they mixed up 'guix refresh' and 'guix pul && guix upgrade'
<civodul>ooh, interesting
<civodul>that means they didn't read the manual nor --help
<civodul>perhaps "refresh" is a confusing name
<efraim>not sure if it's a bug or not, memory usage "shot up" to ~1.5G while compiling crates-io.scm and then it doesn't look like it was released
<efraim>then gain I checked with 'free -m' so it's hardly a real test
<civodul>maybe "guix help" should separate developer commands from "user" commands
<civodul>efraim: it's quite possible i'm afraid :-/
<efraim>I was going to suggest that or "this is a developer command" but we didnt' want to separate users from developers
<civodul>that's with Guile 3.0.2?
<efraim>I on
<efraim>uh, i'll check
<civodul>in the manual we try to be clear about the intended audience of a command though
<efraim>still guile-2.2. It's using the Debian packaged libraries for compiling the guix repo
*efraim is working *slowly* on 32-bit powerpc
<civodul>2.2.7/3.0.2 should do better there
<civodul>though there's still a lot of room for improvement
<efraim>I wanted to look into building guix/base16 and the like and dropping the stack and then compiling the pacakges and build systems and then only afterward compiling the system and scripts
<efraim>or I forget if the scripts could be before the packages
<civodul>i wonder if you could build & run guix-daemon, and then run "make as-derivation"
<civodul>well, probably not on ppc actually
<efraim>i suppose it's worth a try, IIRC the daemon and pre-inst-env are ready to use before loading gnu/* and guix/*
<efraim>"no code for module (guix)"
<raghavgururajan>Hello Guix!
<raghavgururajan>sneek, later tell apteryx:
<sneek>Got it.
<rekado_>civodul: the issue is blank because of the update pause for
<rekado_>luckily I *just* got rsync access to debbugs (Glenn gave it to me earlier but adjusting the firewall only just happened)
<rekado_>so once the performance test on has completed I’ll sync all bugs from there and resume operations for
<PotentialUser-3>Hi, love your work. Just trying 1.1.0 now and the graphical installer fails at partitioning, brings me back to language choice again (tried this three times now). Any ideas?
<apteryx>raghavgururajan: have you experienced crashes also when using linphoneqt? It's not currently usable (but close, it seems).
<sneek>apteryx, you have 1 message!
<sneek>apteryx, raghavgururajan says:
<civodul>rekado_: oh, great!
<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 :-/
<civodul>perhaps we should store it on a squashfs?
<rekado_>the first run (without dropped caches) in mode 3 took 67 minutes.
<civodul>rekado_: for /gnu/store/.links?
<rekado_>I wanted to quickly send a few benchmark results but this is taking a lot longer than I thought.
<civodul>i was hoping statx would help a bit, haven't benchmarked it
<rekado_>mode 3 was supposed to be the fastest of the bunch, wasn’t it?
*civodul checks
<civodul>oh links-traversal.c, nice
<civodul>can you try with statx instead of stat?
<rekado_>should I replace all calls to stat?
<civodul>as in commit 7738a72186583afb3bb2e0a866c8aba130372400
*rekado_ checks
<civodul>on a warm cache it probably makes no difference
<civodul>especially since we have plenty of RAM there
<Veera>PotentialUser-3: try manual install
<Veera>PotentialUser-3: same happened to me with 1.0.1 version
<Veera>PotentialUser-3: though has not tried 1.1.0
<civodul>rekado_: also, we should bench on an idle machine (i just noticed a download from berlin that stalled a bit :-))
<rekado_>berlin is the biggest store we have
<rekado_>“I also found the mailing list not particularly helpful and sometimes even downright rude.” — really? :-/
<civodul>from Reddit? bah
<civodul>perhaps we could do useful profiling on one of the build nodes, for instance
<rekado_>okay, I’ll try on one of the build nodes and abort this run.
<rekado_>huh, exactly 67 minutes
<rekado_>guess it was close to finishing
<rekado_>oh well
<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..?
<lprndn>(and not in the usual kernel build)
<civodul>lprndn: how did you create your custom kernel?
<civodul>efraim may be familiar with those things
<lprndn>civodul: with make-linux-libre*, changing source, #:defconfig and #:extra-version.
<raghavgururajan>apteryx Yes, it crashed. I saw you message regarding a missing package. I am packaging it as we speak. :-)
<sputny>hi #guix, I want to subscribe to the german help-guix mailinglist. maybe I'm stupid, but when i click the "de" button at nothing happens…
<apteryx>raghavgururajan: excellent, thank you :-)
<apteryx>rekado_: Users complaining on Reddit? Can't be.
<smithras>hi guix! It's been a busy day I see :)
<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 I was looking for official source tarball, but it not there.
<raghavgururajan>No occurance of 'quickdialog'.
<efraim>sputny: there's only the one help-guix mailing list but it accepts emails in multiple languages
<raghavgururajan>apteryx I think the it is part of "quickcontrols", because the link you gave me ( points to quickcontrols as source. We already have quickcontrols in guix.
<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�;”
*rekado_ really doesn’t know C
<rekado_>I thought I already had the right includes…?
<pkill9>does browserpass-native not work for anyone else in either icecat or ungoogled-chromium?
***rekado_ is now known as rekado
<mbakke>pkill9: I think it needs some extra configuration, see
<rekado>finished syncing debbugs; it’s just under 10G
<rekado>but there are no ready-to-use mbox files; have to extract those from .log files that contain other stuff.
<civodul>rekado: see the list of includes in "man statx"
<pkill9>mbakke: that worked, thanks!!
<rekado>civodul: I have them all, but still get errors.
*rekado looks at debbugs
*rekado sees this comment in the CGI script: # This is craptacular.
<civodul>rekado: #define _GNU_SOURCE 1 maybe?
<civodul>trial & error
<sputny>efraim: allright. Thanks for clarification.
<rekado>civodul: hah, that’s it! I tried “-D__GNU__” and “-D__USE_GNU” before, but I have no idea what I’m doing
<civodul>yup, don't change __GNU__ and __USE_GNU
<civodul>the former is defined on GNU/Hurd and the latter is internal
<civodul>_GNU_SOURCE if for users
<sammich>hey im trying to write a package for guix (installed on opensuse) and im getting an error /etc/services cant be found, any idea what thats about?
<mbakke>sammich: `/etc/services` is not available in the build container
<sammich>I see, but whats it being used for? I dont refereence it in the package definition and it doesnt get as far as downloading the package for the package itself to be relevant
<raghavgururajan>sneek, later tell apteryx: Fixed linphoneqt crash ( It is ready to be pushed to master. Please use v2 patch. Thanks!
<sneek>Got it.
<pkill9>is it possible to route specific network traffic through a proxy?
<pkill9>on guix system
<pkill9>and if not specific traffic, then all network traffic?
<civodul>sammich: what command did you run and what's the exact output, to make sure there's no misunderstanding?
<sammich>im running `guix build -f guix.scm` the output is this:
<efraim>note: currently hard linking saves -2.93 MiB
<mroh>one page html on gives 404
<civodul>sammich: the build environment for downloads contains /etc/services bind-mounted from the host
<civodul>thus you need to make sure that file is available on your system
<civodul>(/etc/services is a database that maps "http" to 80, and so on)
<civodul>so you need to install the package of the host distro that provides that file
<civodul>it may be called "net-base"
<rekado> should get a Guix line.
<sammich>civodul: ah i see, so it turns out open suse moved it from /etc/services to /usr/etc/services, ill try linking it back
*civodul looks at jonsger
<civodul>obviously jonsger is hiding
<sammich>yup, well linking it seemed to fix it, thank you for the help
<civodul>rekado: that's by Bernard of SuSE, right?
<efraim>malloc.c:2382: sysmalloc: Assertion `(old_top == initial_top (av) && old_size == 0) || ((unsigned long) (old_size) >= MINSIZE && prev_inuse (old_top) && ((unsigned long) old_end & (pagesize - 1)) == 0)' failed.
<rekado>civodul: yes.
<efraim>error from guile-bootstrap-2.0 on powerpc
<nikita`>huh. TIL.
<allana>mbakke: Yes, I have a custom channel.
<civodul>efraim: ouch, that's in libc
<efraim>civodul: thanks, that's what I suspected. I'll probably try dropping glibc to a lower version for the next round
<apteryx>raghavgururajan: you mean core-updates, right? :-)
<sneek>Welcome back apteryx, you have 1 message!
<sneek>apteryx, raghavgururajan says: Fixed linphoneqt crash ( It is ready to be pushed to master. Please use v2 patch. Thanks!
<apteryx>raghavgururajan: sounds good. I'll give it a try a bit later.
<rushsteve1>Hello. I'm trying to use Guix from git to test a package I want to contribute, but every time I run `./pre-inst-env guix build package` I get the error: `no code for module (gcrypt hash)`
<raghavgururajan>apteryx Currently it is in core-updates. But I think it is ready to be pushed to master. as the crash is fixed now.
<lfam>rushsteve1: You need to add guile-gcrypt to your environment. Try `guix environment --ad-hoc guile-gcrypt`
<nckx>Hi Guix. What's the deal with A0C5E3522EF8EF5C64CDB7F0FD73CAC719D32566 (bavier, commit 77704cb1).
<madage>civodul, mbakke: FYI, the possible bug with substitutes I reported here days back turned out to be related to a misconfigured http-proxy on my system config
<rushsteve1>lfam: Oh, yeah. That would make sense wouldn't it... thanks for the help!
<madage>afaiui, the recent commit that enabled a runtime http-proxy setting made my config error to break guix
<lfam>rushsteve1: I have ended up just installing guile-gcrypt into my profile with `guix install guile-gcrypt` because I do a lot of Guix development and it saves time
<madage>so notabug afterall and I won't report it, thanks for your help
<rushsteve1>lfam: I was running in a pure environment, but I should probably just install it to my profile too
<lfam>Right. You can also compose environments like this: `guix environment --pure guix --ad-hoc guile-gcrypt`
<rushsteve1>yeah that's what I did
<apteryx>raghavgururajan: the reason linphoneqt is on core-updates is/was because we needed to build it with a newer Qt/GCC to prevent a compilation failure, IIRC. Does it now build on master?
<guix-vit`>nckx: `xplanet -window -body MARS` seem to work, "somewhat"
<rushsteve1>lfam: Update, installing guile-gcrypt didn't fix the issue
<guix-vit`>strange, some .jpg missen.
<rushsteve1>Same error as before `no code for module (gcrypt hash)`
<rushsteve1>installing guile3.0-gcrypt didn't work either
<lfam>Hm... any ideas, anyone?
<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.
<raghavgururajan>apteryx The patch I sent builds on master.
<rushsteve1>bricewge: yeah that's what I did at first, then I tried guile3.0-gcrypt and a few other things. No luck.
<apteryx>raghavgururajan: I think master is now using gcc7. (gnu packages commmencement)'s gcc-final ultimately inherits from gcc, which is defined as (define-public gcc gcc-7) in (gnu packages gcc).
<lfam>rushsteve1: After you enter the environment, try re-doing the configure and make steps
<lfam>And if you have set a custom GUILE_LOAD_PATH environment variable somewhere, make sure it isn't making it into the pure environment (for example if you set it from bashrc or zshrc
<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.
<rushsteve1>bricewge: `./pre-inst-env guix build midori --keep-failed`
<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 <>. 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
<rushsteve1>Here is the env:
<rushsteve1>Here is the full error:
<allana>Are channels broken with the new release og guix?
<lfam>Okay, I actually have the exact same profile for GUILE_LOAD_PATH as you rushsteve1 :)
<rushsteve1>oh that's neat
<lfam>The z8irn4kxv6s... store item
<rushsteve1>Reproduciblity in action I guess
<rushsteve1>and yeah gcrypt is in there
<lfam>Are you familiar with strace?
<lfam>You could also add strace to the environment and then re-run the command like `strace -f ./pre-inst-env guix build ...`
<lfam>See where it is looking
<lfam>The environment looks correct so I'm not sure what's up. Probably somebody else could figure it out right away...
<rushsteve1>I got 15,000 lines of output from strace
<lfam>You might want to set up logging like `strace -f ./pre-inst-env ... 2>&1 | tee ~/tmp/log`
<pkill9>my system build and my root user's guix are built from the same guix commi,t yet it's rebuilding stuff when i reconfigure, i don't get it
<lfam>Yeah, that's normal. But if you search in there for gcrypt you'll find the right info
<pkill9>i don't think i change my config file either
<rushsteve1>lfam: Aight, there is the output of `strace |grep gcrypt`
<rushsteve1>It seems like it's trying to load from the wrong path, despite GUILE_LOAD_PATH
<lfam>Did you re-do configure and make since creating the environment with '--ad-hoc guile-gcrypt'?
<cbaines>rushsteve1, I'm not following along well, but mixing Guile 2 and 3 things can go wrong
<rushsteve1>lfam: I tried that earlier and nothing changed, but I can try again
<rushsteve1>cbaines: Yeah probably, do you know how I'd fix that?
<lfam>I would try that, and also try `./pre-inst-env env`
<cbaines>I've found I need to clear GUILE_LOAD_PATH and GUILE_LOAD_COMPILED_PATH when using Guile 3 for Guix
<cbaines>rushsteve1, are you trying to run Guix with Guile 2 or 3?
<lfam>Using Guile 3 is still a special case, right? Like, you'd have to go out of your way to do it?
<rushsteve1>cbaines: inside the environment it seems to be using Guile 2.2.6
<cbaines>Ok, that's fine
<lfam>rushsteve1: I notice in the strace log that a different profile is being looked up, /gnu/store/fq44bza85r0... profile
<lfam>That's why I think you need to regenerate your pre-inst-env file
<lfam>I bet if you look in that profile directory, it's missing gcrypt
<rushsteve1>lfam: yeah I added strace to the environment, and gcrypt is still in there
<rushsteve1>Full env command `guix environment guix --pure --ad-hoc guile-gcrypt strace`
<lfam>Okay, I'm going to try to reproduce this from a fresh Git checkout
<lfam>Outside of the environment, can you do `guix describe` and share the result? If that doesn't work, then `guix --version`
<lfam>Also, what Git commit are you on?
<rushsteve1>^ output of describe and --version
<lfam>And in the Git repo, which commit?
<lfam>rushsteve1 ^
<rushsteve1>Just pulled to 7adf6f1be9 so I'm going to try a full rebuild
<lfam>Alright. Currently waiting for `guix pull --commit=90ec7085793700552359d9d409287528437f0280` to complete so that I can match your Guix state
<pkill9>why was pulseaudio designed in a way that they expect it to close after a period of time? it just seems unneccessary, a desktop's sound system is something you expect to always be there
<pkill9>and when pulseaudio closes it disconnects my bluetooth headphones
<pkill9>i guess maybe i should have it configured to reconnect to them when pulseaudio starts
<pkill9>maybe that's the real issue for me, lol
<lfam>Building Guix now rushsteve1....
<rushsteve1>lfam: same
<rushsteve1>nearly done here
<lfam>Changing the subject... tzdata is not even qualified for the staging branch now. Changing it would cause 1439 rebuilds
<lfam>We need to look into this and try to reduce that number
<cbaines>Is tzdata something that changes often?
<mothacehe> civodul: Found out that installer error reporting is broken in 1.1.0 :(
<rushsteve1>It shouldn't be, timezones rarely change do they?
<mothacehe>Fix available here: 40668.
<pkill9>I believe I *finally* worked out the weird behaviour with chromium and pulseaudio
<pkill9>what's happening is that when pulseaudio isn't running, i think if you start chromium and you view a video with it, if pulseaudio isn't runninghten it uses alsa
<pkill9>and then if you run pulseaudio, pulseaudio doesn't connect to alsa
<pkill9>hence why in pavucontrol it says 'dummy output' device
<lfam>rushsteve1: The time zones actually change a lot. Several times per year and in a huge variety of locales
<lfam>Time zones are something people make decisions about on a regular basis
<lfam>Often with only a few days notice
<lfam>So, that's why I think it's important to be able to keep them up to date
<lfam>I've done work in this area previously to keep the number of rebuilds much lower than they are now :/
<lfam>It's a particular problem for Guix relative to other distros because they have no trouble updating the time zones at a moment's notice. We really should not let Guix get out of sync here
<rushsteve1>lfam: Complete build finished, same issue
<rushsteve1>Does it have to do with how I'm running the daemon?
<lfam>Here's an example of a time zone change announced by a national government with 4 days notice:
<lfam>How are you running the daemon?
<rushsteve1>`sudo -E ./pre-inst-env guix-daemon --build-users-group=guixbuild`
<rushsteve1>Outside the env
<lfam>Not sure but it's a wrinkle
<rushsteve1>With a main daemon run by systemd that *should* be unrelated
<lfam>How are you configuring the build, btw? You are doing `./configure --localstatedir=/var`, right?
<roptat>mh... I've downloaded a substitute for texlive, but I'm missing disk space for applying a graft to it :/
<rushsteve1>ah, yup that might be it
<roptat>is there a way to add the substitute to the gc roots so it won't be deleted by guix gc?
<lfam>roptat: Yes, symlink the store item into /var/guix/gcroots
<lfam>I have a long-term symlink in there for texlive-texmf
<lfam>The source code
<roptat>I see, might be useful :)
<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
<lfam>So, I'm not sure what's up here
<rndd>hi everyone! i found http-proxy variable for guix configuration. But how i can set up system proxy settings?
<cbaines>rndd, I see a "Network Proxy" setting in the GNOME Settings interface, if you're using GNOME/Network Manager
<cbaines>I'm not sure if that works though
<rushsteve1>lfam: yeah it looks like the missing --localstatedir on ./configure might have been it
<rushsteve1>Or actually, I just realized I forgot to run the daemon again with ./pre-inst-env when I did the guix build.
<rushsteve1>Would that matter?
<lfam>No, that won't matter
<lfam>Unless you are testing changes to the daemon there's no reason to run it from the Git repo
<guix-vit`>IWAY inkthay eway ouldshay anslatetray ethay Eferenceray Anualmay otay Igpay Atinlay, otay attractway BSDAY-eoplepay
<guix-vit`>`pig <<< 'I think we should translate the Reference Manual to Pig Latin, to attract BSD-people'`
<Blackbeard>Hi :)
<guix-vit`>Hi Blackbeard
***atw` is now known as atw
<rushsteve1>lfam: then yeah, it was the --localstatedir
<rushsteve1>Because it just worked, built all the way and everything
<bricewge>Hello Blackbeard
<Blackbeard>guix-vit`: how do you know my friend who uses OpenBSD and maintained LibertyBSD loves pig latín?
<Blackbeard>liberdiko: hey ! How are you
<rekado>ecbrown: don’t bother with guile-emacs yet. It’s currently broken.
<rekado>the compilation takes *much* too long and eventually times out.
<bricewge>Blackbeard Fine and you
<rushsteve1>lfam: thanks a ton for your help!
<rekado>I started to rebase the wip-elisp branch of Guile to the latest 2.x stable version to see if it makes any difference.
<lfam>You're welcome rushsteve1
<mbakke>apteryx: there have been a couple of merges in which master was merged to core-updates, and then that merged core-updates was pushed to HEAD
<mbakke>I've contemplated a couple of times how to track moving HEADs in git, but haven't gotten around to actually scripting it yet.
<mbakke>apteryx: so to find the last merge, you'll need to look at git's graphs and see when it "changed lane"
<apteryx>mbakke: so core-updates was forced push on master at some point?
<apteryx>force pushed*
<rekado>we don’t force push
<mbakke>apteryx: no, git allows that because that new merged branch is a direct descendant
<apteryx>I see. Thanks for explaining.
<mbakke>i.e. you can merge master into core-updates now, and push that new branch back to master
<mbakke>I think we should discourage such merges though since it's difficult to figure out when it happened
<guix-vit`>Blackbeard: i didn't know about that, but read that OpenBSD maked some security patches to bsd-games.
<mbakke>apteryx: it may be easier to scrape the guix-commits archive
<apteryx>I'll explore the graph when I have a bit of time later, thanks
<lfam>Hey mbakke, I'm looking at TZDIR and libical and saw your comment about libical 3.1.0 from <>
<lfam>I'm curious where you found reference to 3.1.0?
<lfam>Maybe we should patch libical to respect TZDIR like in nixpkgs
<lfam>Right, I saw that
<lfam>They don't give any indication of when this might be release, though
<lfam>Ohhh I found their release notes with "future" changes
<lfam>I wonder about the timeline
<lfam>I regret not noticing this earlier in the core-updates cycle
<lfam>Maybe for the next staging cycle we can squeeze it in
<lfam>The tzdata-for-tests package is woefully underused :(
<mbakke>lfam: looks like it can take a while:
<mbakke>patching it sounds good to me
***vagrantc_ is now known as vagrantc
<cbaines>how is core-updates coming along mbakke?
<mbakke>cbaines: for x86_64 it's pretty much on par with 'master', but armhf and aarch64 are still a few weeks off
<cbaines>I've noticed that it's been evaluated successfully lately on
<cbaines>which is a good sign at least
<lfam>Do we have any visibility into substitutes requested per-architecture? I'm curious about how much armhf is actually in use these days
<lfam>It's really a poor platform for general purpose computing and 64-bit ARM is so inexpensive now
<cbaines>I've been looking in to why the Guix Data Service can't process core-updates
<mbakke>I don't think we have such metrics lfam.
<cbaines>I believe I've tracked the issue down to a regrssion when building Guile with libgc 8, rather than 7
<mbakke>Anyone up for packaging 'piwik'?
<mbakke>Errh, apparently 'matomo' now.
<mbakke>cbaines: ouch
<cbaines>mbakke, lfam Guix has a package for goaccess. I've used that when looking at NGinx logs before
<cbaines>you could probably just run that against the logs on
<cbaines>mbakke, back to core-updates though. I've just built Guile 3 with libgc-7, and I can't reproduce the issue. So I'm wondering if it would be feasible to stick with libgc-7 for now?
<cbaines>(I'll send an email about this shortly as well)
<cbaines>This is the relevant bug about guile/libgc issues:
<mbakke>cbaines: I guess we could graft it
<mbakke>though it would be better to fix Guile, of course
<cbaines>I'm not sure if it's an issue with guile, or libgc
<mbakke>cbaines: it's reminiscent of
<cbaines>mbakke, it's a little hard to tell from the stacktrace, but that looks like the exact same issue
<mbakke>cbaines: yet that particular problem was seemingly fixed in
<vagrantc>sometimes "guix build FOO ... The following derivations will be built: ..." lists the exact same derivations multiple times ...
<vagrantc>is this plausibly because of packages with multiple outputs?
<civodul>vagrantc: hmm no, that sounds fishy; exactly the same, really?
<civodul>or same name different hash?
<vagrantc>same hash
<vagrantc>i noticed it a couple times yesterday, and then today
<vagrantc>what was i ever thinking adding openjdk* test suite for diffoscope.
<vagrantc>when there are no substitutes ... that one is brutal
<civodul>super weird
<pkill9>hello guix
<Blackbeard>pkill9: hey
<plstohelp5>there we go
<plstohelp5>ive been trying to get my irc client to behave
<plstohelp5>but im doing this on the freenode web client
<plstohelp>there we go
<plstohelp>I'm going to be back later for guix help, I want to learn some stuff
<plstohelp>going to try building a package at some point
<pkill9>the bikeshedder in me thinks pulseaudio-service-type should be renamed to pulseaudio-configuration-service-type
<sirgazil>I just run "guix upgrade" and it took more than 30 seconds to display any output. Something similar happens with "sudo guix system reconfigure". I haven't tried with other commands yet.
<civodul>sirgazil: is that a regression for you, and if so, do you have the commit that didn't have that problem?
*rekado is gonna push 40629 (with documentation) soon.
<sirgazil>civodul: Guix has been slower to display output, for some weeks for me, but I don't know when exactly the problem started.
<sirgazil>Often I run into little bugs that I don't have time to report.
<civodul>rekado: i had completely overlooked that one, looks cool!
<sirgazil>One thing I remember is that it was around the time Guix was upgraded to use Guile 3
<sirgazil>Aaand, the upgrade failed:
<sirgazil>guix upgrade: error: build of `/gnu/store/lwyn22pmyfxwy9whpvdsdp69n3zhl7qh-python-jedi-0.17.0.drv' failed
<rekado>pushed it
<sirgazil>command "python" "-m" "pytest" failed with status 1
<rekado>incidentally, this “fixes” issue 15284
<civodul>sirgazil: "guix pull -l 3w" shows the revisions you pulled over the last 3 weeks
<civodul>if you could do a quick comparison of "guix upgrade" or so to find out, that'd be great
<civodul>run "time guix upgrade -n" for instance
*rekado just closed a (wishlist) bug from 2013