IRC channel logs


back to list of logs

<vagrantc>looks like the answer regarding bug subscription is "no":
<voalvarez>hello, I'm Victor Alvarez. Im in the process of applying to the outreachy intership to participate on GUIX project. Currently Im a Computer Engineering student
<Apteryx>voalvarez: cool! welcome :)
<civodul>Hello Guix!
<rekado>voalvarez: Hi! Please make sure to complete the eligibility check on the Outreachy website and then try to make a contribution to Guix that you can record for you application.
<rekado>voalvarez: the application deadline is tomorrow.
<rekado>voalvarez: have you already installed Guix?
<rekado>do you know of an easy equivalent for “guix environment --pure” but for “activating” profiles?
<rekado>I usually recommend starting a sub-shell, sourcing etc/profile, and then working in that sub-shell.
<rekado>but this augments the environment. It doesn’t replace it.
<rekado>guess I’ll have to use --search-paths for that.
<civodul>yes, --search-paths is more expressive than etc/profile
<voalvarez>rekado: yes
<danyspin97>elogind is complaining about cgroups (No data available). Is there any guide to setup it for custom rc files? I dind't find anything.
<g_bor>hello guix!
<g_bor>It seems that pivot_root test is failing on ubuntu.
<g_bor>I've already asked a question about this, it is the case that the shared mounts in ubuntu is causing this.
<g_bor>What would be the drawback of unsharing the mount namespace before pivot_root?
<g_bor>Hello guix!
<civodul>hey g_bor!
<g_bor>I've already asked this, and this seems to be coming up again, is that pivot_root fails when there are shared mounts.
<civodul>that's not a question :-)
<g_bor>Would there be any disadvantage to unshare the mount namespace befor pivot_root?
<g_bor>This seems to affect virtually all systemd based systems.
<thomassgn>guix size: error: no available substitute information for '/gnu/store/1g8h7q3wx3qxn8vpygckkb11q2sr56q1-screen-message-0.25'
<thomassgn>I mean screen-message is installed on my system and I'm finishing up before sending the definition as a patch. What am I doing wrong?
<civodul>surely /gnu/store/1g8h7q3wx3qxn8vpygckkb11q2sr56q1-screen-message-0.25 does not exist on your system, am i right? :-)
<civodul>g_bor: you mean in guix-daemon?
<thomassgn>I thought no, but it actually does...
<thomassgn>ton@merlin > ll /gnu/store/1g8h7q3wx3qxn8vpygckkb11q2sr56q1-screen-message-0.25 gives me bin/ and share/ ... wtf
<civodul>then it must be "invalid", i.e., it's the remnants of a failed build
<g_bor>Yes, in guix-daemon. And I guess it also seems to trigger this test failure test-name: pivot-root
<g_bor>location: /home/masha/src/guix/tests/syscalls.scm:156
<civodul>hmm, tricky enough to warrant a detailed report on bug-guix i'd say :-)
<thomassgn>civodul: I just realized, I was running guix build --rounds=5 at the same time, it just finished. This one specific path was for one of the five builds. Now guix size responds as expected....
<civodul>heh, ok
<g_bor>civodul: This has also came up in a thread, where we tried to make a wayland configuration working. Unsharing the mount namespace helped there. I could not look at the test failure in detail yet.
<thomassgn>I've read through the submitting patches section just now and would like to send two package definitions, is there any best practice for labeling or similar?
<civodul>just one patch per package with an appropriate commit log, as discussed in that section
<civodul>but don't worry too much about that, we'll tell you if anything needs to be adjusted
<g_bor>civodul: this problem is referenced here:
<civodul>bug-guix please :-)
<civodul>ACTION add CI monitoring support to 'guix weather'
<g_bor>civodul: I've checked the bugtracker, we seem to have an open bug on that already, it's
<civodul>oh indeed
<thomassgn>um, trying to get networking on a 'guix system vm conf.scm' result. '-net user' does not seem to work. Do I need to be part of a group or the script as root or something?
<thomassgn>I ran dhclient in the vm, and seem to get an ip, but I don't have access to network and I can't access the ip from my host.
<thomassgn>I mean I can't ping from vm
<rekado>thomassgn: AFAIK it is normal that ping won’t work in a VM.
<efraim>i tried guix pull and guix pull with the new branch on my aarch64 board with 4gb of ram, 32 minutes regular and 39 with the new branch
<civodul>efraim: thanks for trying
<civodul>not great results indeed
<civodul>the main thing is that a subsequent pull should be faster
<dijong>hi, what is the proper way to start a postgresql server in guixsd? i tried installing postgres@9.6 and running "herd start postgresql" and variants, but it says the service can't be found. is there just no service file that comes with the package?
<roptat>dijong: you need to install the server in your os configuration
<roptat>you will need postgresql-service documented in
<roptat>and you can read more about system configuration at
<roptat>need to go, but others may be able to help
<roptat>basically, you need to add (postgresql-service) in the (services …) declaration in /etc/config.scm (or whatever you called that file)
<dijong>roptat: thank you, i changed my config.scm to say "(services (cons* (postgresql-service) %desktop-services))" and i'm running "guix system reconfigure /etc/config.scm" now :-)
<dijong>does it matter whether i run "guix system reconfigure..." as root or a normal user? i understand they have different packages, but i'm running my reconfigure as my normal user now and it's downloading a lot of extra things
<snape>dijong: you should run it as root (with 'sudo -E' for example)
<snape>system reconfigure is system wide, it touches lots of files that a normal user can't touch
<ng0>reconfigure will run as far as it can when invoked without superuser rights. it will stop at the point where the files are touched that can not be altered by your user.
<thorwil>been there :)
<thomassgn>dijong: youll see soon it will stop and complain about missing rights for touching things
<thomassgn>But, by that time it will have built your system for you. So you don't have to fix it just yet
<dijong>snape: thank you, i sent SIGINT to my initial reconfigure attempt (from the normal user) and when i try to run it from my sudo -i shell i get 'guix system: error: stat: No such file or directory: "root"' at the very beginning -- i'm checking to see if it may have something to do with my config.scm
<thomassgn>I fudge that step all the time :)
<thorwil>i have a git clone of guix with a changed desktop.scm, built with --localstatedir=/var. as root, i did `./pre-inst-env guix-daemon --build-users-group=guixbuild`
<snape>(postgresql activation won't work without superuser rights anyway)
<thorwil>then `./pre-inst-env guix system reconfigure /etc/config.scm`
<thomassgn>back to the vm, I can actually get pages from online, and I can access the http server running on port 8080 from inside the vm. I am still unable to find the ip of the vm so I can accesss its webpage from my host though...
<thomassgn>rekado: do you have any more info on this?
<thorwil>but now guix is building and testing loads of stuff :/ i thought this way, it would pick up things from the store
<snape>dijong: can you run it from a normal shell with 'sudo -E'?
<dijong>snape: yes, "sudo -E guix system reconfigure /etc/config.scm" yeilds the same error. i think it has to do with these lines in the (operating-system) part of my config.scm:
<snape>dijong: device should be "/dev/mapper/root" I believe
<dijong>snape: ah yes, that would explain why i have to run "cryptomount -a" in coreboot grub before chainloading to guix grub every time haha
<dijong>got past that error now and it's reconfiguring!
<snape>but in the docs it's written "root"...
<snape>dijong: did adding "/dev/mapper" help?
<snape>(if it's the case, the docs should probably be modified)
<dijong>snape: yes, changing it from "mapper" to "/dev/mapper/root" in device got me past that first error, but it's still reconfiguring
<snape>good! Would you like to patch the documentation?
<dijong>i did copy that line from the docs i think, so that would make sense :-) i would love to submit a pull request! i'm still getting familiar with the whole debbugs way of doing things, so it may not be until this weekend that i can figure all that out, but possibly later today
<snape>it would help you getting used to it!
<snape>we don't submit pull requests, instead we send patches
<snape>by email, to
<snape>and you can use git send-email for this
<snape>anyway take your time :-)
<thorwil>wow. now building python, apparently. `./pre-inst-env guix system reconfigure /etc/config.scm` is not doing what i expected
<thorwil>and then a failure:
<thorwil>which has nothing to do with the itsy bitsy addition to desktop.scm, obviously
<thorwil>mbakke: hi! i find myself unable to test the service i added to desktop.scm for creating /tmp/.X11-unix
<thorwil>it's trivial, but my error-rate is too high to not test even the mundane :}
<mbakke>thorwil: Could it be that your working directory is "dirty", i.e. contains unrelated changes? You should be able to get a substitute for Python.
<mbakke>What does `git status` say?
<thorwil>mbakke: aside of desktop.scm, it lists lots of *.po files as modified
<thorwil>plus an untracked gnu/packages/perl.go.Y4WK66
<mbakke>The *.go.$RAND files can be deleted, they're the result of an aborted compilation.
<thorwil>ah right, there was a `make check` that got stopped by my system freezing
<mbakke>Also the .po files can be removed with `git reset --hard`, but that will also undo your desktop.scm change.
<mbakke>Odd that you have to build Python, how did you invoke "./configure">
<thorwil>./configure --localstatedir=/var, afair
<thorwil>ok, backed up desktop.scm (again), make clean, git reset --hard, git pull
<thorwil>more after dinner :)
<thorwil>this time, `guix environement guix` is triggering builds ... now again busy with Python-2.7.14
<thorwil>guix environment: error: build failed: build of `/gnu/store/2vzx3jk35ff9ghsq8b8ppgrqqm8ikpxq-curl-7.59.0.drv' failed
<lfam>thorwil, mbakke: It's not necessary to use `git reset --hard` to clean up the PO files. You can just do `git checkout po`
<lfam>This will leave your other changes around
<efraim>not `git checkout -- po' ?
<lfam>According to my history, the -- separator isn't needed
<lfam>But, I think it can't hurt
<lfam>Is there a 'po' command to `git checkout`?
<efraim>i would assume `guix checkout po` would checkout the 'po' branch
<efraim>it might just be like `rm foo bar baz', there's no possibility of problems like `rm foo -rf bar' vs `rm -- foo -rf bar'
<lfam>efraim: Only if there is a po branch (I don't have one). Otherwise it checkouts of the files in the po directory
<lfam>Err... checks out
<lfam>So yeah, it's safer to use the --
<thorwil>so this could go to the patch list:
<thorwil>if it wasn't for a failing python build keeping me from trying it out
<lfam>thorwil: Hm, a failing Python build (or any building of Python) is not expected!
<efraim>the new ram I got worked perfectly, my laptop now has 4GB of ram!
<thorwil>ACTION used to think 3.8 GiB would be plenty, until he tried editing raster images in 10000 x 10000 plus range
<lfam>My next computer will only have RAM
<efraim>My x120e with a dead screen had 8GB
<apostolis>Hello, how can I use the qemu image? the instructions show how to use a iso.
<lfam>apostolis: The instructions are here:
<lfam>Please let us know if you need more guidance
<lfam>And, which instructions are about using an ISO?
<apostolis>Probably, I did not decompress the image. (the ones you pointed)
<lfam>Ah, that's an important step
<lfam>There are actually two sets of instructions, one for installing GuixSD in a VM, and one for running a pre-installed GuixSD in a VM
<lfam>If you want to test the system installation procedure, use the former. Otherwise, the latter is fine
<apostolis>Oh, yes, I ware referring to the former.
<apostolis>lfam :
<apostolis>If you look at the instructions for GuixSD QEMU image, it tells people to use a usb iso image.
<lfam>apostolis: It's referring to the GuixSD installer image (the first one on the download page)
<lfam>The QEMU image is a pre-installed bare-bones system
<apostolis>Yes, but you download a VM image.
<apostolis>It needs to point to the page you gave me.
<apostolis>"Running guixsd in a VM"
<lfam>They are different things. You can choose to install GuixSD in a VM, or run a pre-installed GuixSD in a VM.
<lfam>Hm, I see
<lfam>The phrase "Installation Instructions" is a bit misleading under the QEMU image download. And it does refer to something else, indeed
<lfam>Okay, I'll fix this shortly
<lfam>apostolis: I sent a fix in for review
<apostolis>:) Nice.
<lfam>Thanks for pointing this out :)
<jlicht>hey guix!
<bavier`>hello jlicht
<jlicht>o/ bavier`
<jlicht>Finally got my minifree T400 to work properly with GuixSD :D
<thomassgn>in guile, I want call-with-output-file but if the file doesn't exit it fails. How do I make it create the file if not exists?
<thomassgn>mbakke: this might be the reason why I used the more dificult lambda in fpm2.scm - but there should be a way around yes?
<rekado>thomassgn: it creates the file, but not the directory.
<thomassgn>huh, I see. but does the other one (open-output-file) do that? create the dir?
<efraim>You could hunt down mkdir-p from the guix source code
<thomassgn>mm, definitely. Just thought it was a bit weird that call-with-output-file fails to create file or folder while open-output-file works.
<jlicht>Does anybody else have issues wrt X.509 cert verification for e.g. `guix download' on the domain?
<lfam>jlicht: Did you follow the related steps in the manual, section Application Setup:
<lfam>It works for me, which is why I ask
<lfam>Basically, you need to install nss-certs and / or set some environment variables
<jlicht>lfam: thanks, but I have all of SSL_CERT_{DIR,FILE}, GIT_SSL_CAINFO and CURL_CA_BUNDLE setup
<jlicht>+ it works with the nodejs domain
<jlicht>just not github
<jlicht>if it's not too much trouble, could you `guix download' the latest release of
<jlicht>just to be sure nothing iffy is going on ;-). It seems we need a more recent version of http parser to properly build the just-now-release security update for nodejs
<lfam>jlicht: Sure, I got hash 17a7k3nxv2p1sp2x5d89wr51vk770753vz6qnlp2gz7nkgwwcxvj in response
<lfam>Exactly what error do you get?
<jlicht>the hashes match though :-)
<jlicht>could it have anything to do with the openssl update?
<lfam>Hm... I doubt it since I did test things. But I'll be right back :)
<lfam>jlicht: Can you share the output of `env | grep -i ssl`?
<jlicht>SSL_CERT_DIR seems to be a bit weird though :O
<jlicht>ah, because it is already set by sourcing `$GUIX_PROFILE/etc/profile'
<lfam>I would try again after making that variable contain a single directory
<jlicht>hey lfam: It works now! Although admittedly the documentation at does not make a clear distinction between SSL_CERT_DIR and SSL_CERT_FILE (wrt SSL_CERT_DIR already being set when sourcing $GUIX_PROFILE/etc/profile)
<jlicht>thanks for helping me nonetheless. PEBKAC is always difficult to self-diagnose :)
<lfam>That was hardly a PEBKAC issue :)
<jlicht>also, yay node security update in Guix within 6 hours \\o/