IRC channel logs

2020-04-09.log

back to list of logs

<mbakke>rekado: let's coordinate one day and add the Linux template on all the build nodes so we can create pretty aggregated graphs :-) should deactivate the bot first.
<pkill9>rekado: can someone upload the qemu image of guix running on Hurd from the blog post? it will take a long time to build on my laptop :|
<xelxebar>sneek: Later tell pkill9: Here's the original blog post about Guix on Hurd: https://guix.gnu.org/blog/2020/deprecating-support-for-the-linux-kernel/. It has a link there to a prebuilt image.
<sneek>Will do.
***ChristopherParke is now known as Christ4
***Christ4 is now known as Christ6
<xelxebar>sneek: Forget it
<sneek>Consider it forgotten.
***wshimmy_ is now known as wshimmy
<Blackbeard>can I tell you how awesome guix is
<Blackbeard>hahaha
<Blackbeard>I just, I want to contribute to emacs and it is so nice to be able to do
<Blackbeard>$ guix environment emacs
<raghavgururajan>guix-vits Intresting and weird. I am confused for not having seg fault. xD
<raghavgururajan>str1ngs Thanks so much for the patch
<raghavgururajan>sneek, later tell bricewge: For xfe, I have sent v2 patch to #40487.
<sneek>Okay.
<str1ngs>raghavgururajan: no problem
<xelxebar> https://guix.gnu.org/manual/en/html_node/G_002dExpressions.html#index-cross-compilation
<xelxebar>That example. lol
<xelxebar>brendyyn: Getting that error message again about failing to build dependencies, in case you still want it: https://paste.debian.net/1139244/
<xelxebar>It comes from a guix pull on a new machine, in case that matters.
<brendyyn>xelxebar: I don't really know what to do about it. You should post a bug report.
<brendyyn>maybe you can produce more debugging output with --debug=3 or somesuch
<raghav-gururajan>bricewge, seg-fault is fixed in v2 patch. str1ngs helped me with a patch.
<raghavgururajan>sneek, later tell apteryx: I have sent a patch to #40264, to add mirror and fix some formatting, in linphone.scm.
<sneek>Got it.
<xelxebar>brendyyn: Thanks. Crafting a bug report now. The --debug flag is helpful
<bricewge>raghavgururajan: I saw that.
<sneek>Welcome back bricewge, you have 1 message!
<sneek>bricewge, raghavgururajan says: For xfe, I have sent v2 patch to #40487.
<bricewge>You need to find a committer now
<raghavgururajan>Cool!
<raghavgururajan>str1ngs Do you have commit access?
<bricewge>raghavgururajan: The list of commiter is here https://savannah.gnu.org/project/memberlist.php?group=guix
<bricewge>I didn't know there was that many people with commit access though
<raghavgururajan>bricewge Oh wow, I didn't know that.
<civodul>Hello Guix!
<Blackbeard>civodul: \o/
<bricewge>Hello
<str1ngs>raghavgururajan: I don't sorry
<raghavgururajan>str1ngs That's okay.
<raghavgururajan>civodul, Will you be able to push #40484 and #40487 please?
<str1ngs>I just send my patches, and eventually when someone has time they look at them :)
<raghavgururajan>đź‘Ť
<str1ngs>I really need to find some to replace xcape . which does not work with wayland.
<str1ngs>something*
<civodul>hey raghavgururajan!
<civodul>i'm currently focusing on preparing the release, but there are ~40 other committers so don't worry :-)
<civodul>maybe send a ping to these issues and someone will pick it up eventually
<raghavgururajan>civodul Cool! :-)
***apteryx_ is now known as apteryx
<kondor[m]>man, packaging java seems such a chore
<guix-vits>Hi Guix.
<str1ngs>hello guix-vits
<bricewge>hi
<str1ngs>guix-vits: I still have not found a replacement for xcape in regards to sway.
<bricewge>str1ngs, guix-vits: https://github.com/david-janssen/kmonad#what-can-i-do-with-kmonad
<bricewge>It uses uinput to inject key press. I bever used it though
<bricewge>There is already a service in Guix too
<str1ngs>brendyyn: does this work with wayland?
<str1ngs>mainly what xcape does for me is modifies SPC key when held down to become CTRL. other wise known as space modifier.
<bricewge>str1ngs: I don't use wayland, but since kmonad is tapping into the uinput kernel module it should work everywhere.
<bricewge>Probably on the console too.
<bdju>str1ngs: I found a few things you can try. 1) https://gitlab.com/interception/linux/plugins/caps2esc 2) https://github.com/wbolster/evcape 3) https://github.com/myfreeweb/evscript
<str1ngs>bricewge: that might be more ideal
<bdju>(maybe ignore the second one, I don't see a license and it hasn't had updates in a long time)
<str1ngs>bdju: thank you I will look at those again.
<guix-vits>thanks, i'll try those
<str1ngs>bricewge: I think I can get kmonad to work. thanks
<rekado_>Hi Guix!
***rekado_ is now known as rekado
<rekado>mbakke: thank you for adjusting the trigger
<rekado>we can disable the bot in Zabbix. It’s just the IRC notifier medium.
<guix-vits>Hi rekado.
<rekado>hmm, my messages to help-debbugs are left unanswered :(
<numerobis>Hi #guix! I few months ago I enquired about the possibility of using Radicale as a guix service. I was told that such a service was not implemented in guix yet, but that I could write one by following the implementation of another service, of which I forgot the name. Now that I have a bit more time on my hands, I am thinking about having a go at writing a service for Radicale, and I was wondering
<numerobis>whether someone could suggest another service for me to look at for inspiration?
<guix-vits>numerobis: did you'd a look at the git-clone's dir gnu/services/?
<civodul>numerobis: if forgot what Radicale is, but you could look under gnu/services at a service you're familiar with, say openssh
<civodul>there's also a couple of talks on the intertubes with an intro to services
<numerobis>guix-vits,civodul: Thanks, I will check that, but what exactly are intertubes? Would you by any chance have a link to that. I had a look at the services in gnu/services, but I remember that someone mentioned a specific one that could be useful. Radicale is a calendar server. :)
<rekado>intertubes = the internet
<PlasmaStrike>Radicle is also something for git https://radicle.xyz/
<bricewge>numerobis: Looking at how it is done in NixOS. Your service in guix will need to extend the account-service-type to add the group and user "radicale" and the sehpherd-service-type to lanch the radicale server.
<numerobis>rekado: ah, got it, thanks!
<numerobis>bricewge: Great, thanks for the tips. By the way, how does one look for something in the IRC logs? Do you download and then grep?
<bricewge>numerobis: You were suggested to look into dkim-proxy-out http://logs.guix.gnu.org/guix/2019-09-05.log#112044
<numerobis>bricewge: amazing, thanks. I assume you didn't browse the log page by page?
<rekado>search is not implemented for the log viewer; if you want to add search support to the logs page, please consider sending a patch for this Guile application: https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/hydra/goggles.scm
<bricewge>I used the search in Matrix :p
<rekado>I’d be very happy to merge your patch!
<numerobis>rekado: thanks! I'll start with the radicale service, but good to have ideas for other possible contributions!
<rekado>I vacuumed the Guix database on ci.guix.gnu.org and it went from 14G to 10G. Still very big.
<civodul>woow
<civodul>rekado: the /var/guix/db/db.sqlite one?
<str1ngs>bricewge: thank you for suggesting kmonad. this is even better then xcape. much appreciated
<bricewge>It seems really cool: QMK for any keyboard
<str1ngs>though my mouse is a trackpad on my keyboard and it stops working lol
<str1ngs> /dev/input/by-id/usb-Logitech_USB_Receiver-if02-event-mouse there is no event-keyboard
<PlasmaStrike>you also have xkeysnail for changing bindings, never saw kmonad before it looks nice:)
<rekado>civodul: yup
<str1ngs>PlasmaStrike one nice think about kmonad is it works from console
<str1ngs>thing*
<civodul>rekado: impressive; i wonder how many entries ValidPaths and FailedPaths contain
<kondor[m]>Did anyone try to package the Brave browser? They claim to be "free and open source"
*guix-vits "''failed to perform a TLS handshake'' -- ok, i'll use another dns, dear ISP."
<guix-vits>kondor[m]: they had some open issues on GitHub, if i'm remember well, about freeDroid. idk, though.
<Blackbeard>guix-vits: hello
<Blackbeard>kondor: from my point of view, their "business model" of substitution of advertising is illegal.
<guix-vits>Blackbeard: Hi hi :)
<kondor[m]>Blackbeard: did anyone sue them yet? :)
<Blackbeard>kondor: I don't know. But I have read that they have had trouble with it and had to do changes
<Blackbeard>guix-vits: what are you working on?
<guix-vits>Blackbeard: nothing now.
<guix-vits>do you have some task for?
<Blackbeard>guix-vits: I've been playing with org-brain. Not really proficient yet, but I am enjoying it
<Blackbeard>Although I will try to package org-roam and probably use that
<kondor[m]>Blackbeard: https://brave.com/braves-response-to-the-naa-a-better-deal-for-publishers/
<kondor[m]>though this is all from 2016
<Blackbeard>kondor: that seems nice. I can't believe it's been 4 years already...
<kondor[m]>Blackbeard: time flies , and so much to do ... :D
<kondor[m]>guix is ooold :D
<kondor[m]>and i'm quickly turning into a graybeard hacker
<damo22>do .scm recipes have built-in tests? sorry for cross posting
<damo22>(20:05:02) damo22: i wonder if gitlab could add a feature to gitlab-runner that caches guix, a new executor for gitlab-runner that uses guix
<guix-vits>damo22: packages are built from sources (either on user's machine or on a substitutes server), with an XYZ-build-system (gnu-, meson-, cmake-...); most of them call "test", or "check", or a such -- by default.
<damo22>guix-vits: im new to guix, but i have a feeling it could be very useful to be able to run build tests of upstream git repos using the guix machinery
<damo22>eg, why not harness the "free" compute that CI services provide to build guix recipes using the code from new commits
<damo22>not for the purpose of providing substitutes, because no one could trust them, but just to test the code builds
<Blackbeard>kondor: that's nice
<guix-vits>damo22: git of project X have a target "check" in it's Makefile; `guix build X` will run the `make check`.
<Blackbeard>I'll give brave a try
<damo22>guix-vits: yes, so `guix build X` will download substitutes or use local guix cache where possible?
<damo22>so a CI server needs to keep the cache somehow for most caching benefit
<guix-vits>damo22: idk how it's works
<alextee[m]>damo22: iiuc, guix uses hashes for everything so you don't need to trust the server to know that what you're getting is correct
<damo22>alextee[m]: so it has reproducible builds?
<alextee[m]>damo22: yes, reproducible builds are baked into guix as far as i know. maybe there are exceptions
<rekado>yes, but you still need to trust the server because we don’t look up builds by output hash
<damo22>rekado: good to know
<rekado>there are fixed output derivations where we record the hash in Guix and look up a matching result from different locations
<rekado>e.g. for source code downloads where the hash is known in advance
<damo22>im curious if anyone has thought of a way to use gitlab CI with guix
<rekado>I have
<rekado>one of my colleagues wanted to use it with Guix
<damo22>thats great
<rekado>but I find it rather inelegant as you’d have to arrange for all build requisites to be copied to the CI server first
<rekado>Guix can build Docker/Singularity images or tarballs, of course.
<damo22>yeah, i was thinking to integrate the build requisites into the gitlab runner cache
<rekado>but that’s still a lot to copy around
<damo22>make it integrated into gitlab ce
<rekado>go for it!
<marmulak>ok so I played with shutdown again, apparently it's not the real shutdown command, but rather a stand-in for halt
<marmulak>so options like -r don't work, doesn't accept time argument
<damo22>rekado: where is guix storing the build products?
<marmulak>I guess maybe doing a proper shutdown or restarting has to be invoked in a different way, maybe something shepherd does
<brendyyn>marmulak: loginctl poweroff ?
<rekado>damo22: everything ends up in /gnu/store
<rekado>marmulak: shepherd provides halt and reboot.
<marmulak>lol
<rekado>“halt” is for a proper shutdown
<marmulak>ok good
<marmulak>I've done halt before but the machine shut off so fast I thought maybe the system was not shutting down nicely
<marmulak>but maybe it's just a fast thing
<damo22>on my gnu/linux system halt does not poweroff the machine it just terminates everything and sits idle, but poweroff calls acpi shutdown
<marmulak>hmm
<damo22>sorry for noise
<marmulak>damo22: is it guix system?
<damo22>no
<marmulak>in my guix vm "halt" powers off, which is good
<marmulak>I just realized guix doesn't use systemd
<damo22>when i realised a compiler cannot be bootstrapped without an existing binary compiler, i realised why its so important to have existing binary distros
<guix-vits>marmulak[m]: `df -h| grep systemd` :D
<marmulak[m]><guix-vits "marmulak: `df -h| grep systemd`"> 🤔
<rekado>damo22: you might like the work that has been made to implement an ever smaller bootstrap in Guix
<rekado>damo22: https://guix.gnu.org/blog/2019/guix-reduces-bootstrap-seed-by-50/
<damo22>rekado: yeah i heard about that, its impressive
<damo22>windows users would need the stage0 bootstrap because they have no native compiler in most cases, i consider them in disaster recovery mode
<xelxebar>brendyyn: I sent in a bug report with the guix pull --debug=3 output. The first reply menioned that build can fail *because* of the --debug flag... :/
<brendyyn>Haha
<brendyyn>I was trying to help ;<
<xelxebar>Hehe. No worries. The build was failing already anyway, so it's good to know that --debug is dangerous.
<dhanvanthri>10/10 would reccomend.
<civodul>roptat: hello!
<civodul>roptat: any idea about the "syntax error" and all the numbers at https://berlin.guixsd.org/log/czsdfjykhlc4ngjdva17i4rglpnh86fl-guile3.0-guix-1.0.1-15.0984481 ?
<civodul>for "POXREF doc/guix-cookbook.de.texi"
<gfleury>hello
<gfleury>i need pod2man in my build environmnent
<gfleury>which package to install
<ngz>gfleury: perl
<gfleury>ngz: thank you!
<civodul>mbakke, rekado & all: any comments on the draft 1.1.0 release notes i pushed to guix-artwork the other day?
<civodul>i'm sure i'm missing important things i didn't follow closely
<civodul>especially under the distro heading
<civodul> https://git.savannah.gnu.org/cgit/guix/guix-artwork.git/tree/website/drafts/guix-1.1.0-released.md
<mbakke>civodul: should we mention some of the new services?
<mbakke>also maybe the brand new proxy support for guix-daemon
<mbakke>also, s/run on/runs on/ i think, in "Guix now run on Guile 3"
<civodul>mbakke: yes for the typo, and yes for new services!
<civodul>proxy support will be in NEWS, maybe unnecessary in the post?
<civodul>here's the NEWS i have so far: https://paste.debian.net/1139305/
<civodul>i'm probably missing stuff under "Distribution"
<civodul>have people tried to compare the time for "guix build guix" (Guile 2.2.6) vs. "guix build guile3.0-guix" (3.0.2)?
<civodul>i haven't tried actual measurements on the same machine
<lprndn>hello guix!
<bricewge>hey lprndn
<lprndn>thanks for the feedbacks on the lightdm service. working on it!
<simonsouth>Anyone else seeing issues with guix fetching packages from ci.guix.gnu.org?
<civodul>simonsouth: what kind of issue?
<simonsouth>civodul: Connections failing or downloads stalling.
<simonsouth>Haven't seen this before this morning. Not impossible it's an issue on my end, but everything else seems to work fine.
<civodul>ah oh
<civodul>i haven't downloading much today
<civodul>*downloaded
<bricewge>lprndn: I hope it'll get merged :)
<Parra>it seems like Guix CI is failing, did anyone experience it?
<lprndn>bricewge: me too!
<simonsouth>Parra: I was seeing connection errors and stalled downloads from ci.guix.gnu.org earlier, if that's related.
<Parra>yeah, it seems it has problems
<rekado>I don’t see anything wrong with the server.
<rekado>sure it isn’t just ncsd caching previous failures?
<civodul>Parra, simonsouth: could you paste the output of failing downloads?
<simonsouth>civodul: guix substitute: error: connect: Connection timed out
<simonsouth>substitution of /gnu/store/y76d9pxifzk8n43di92hfr2zxqxc1liw-mpfr-4.0.2 failed
<simonsouth>killing process 2746
<simonsouth>guix system: error: some substitutes for the outputs of derivation `/gnu/store/3amyj4a2xr3a6pn1yic6qg0ka4bxy77n-mpfr-4.0.2.drv' failed (usually happe
<simonsouth>ns due to networking issues); try `--fallback' to build derivation from source
<simonsouth>...when building a disk image using "guix system disk-image"
<simonsouth>civodul: Also, a bit later:
<simonsouth>downloading from https://ci.guix.gnu.org/nar/fdbjkcbw5n8qaf6asq4i6wqwj4hvdpl1-ghostscript-9.27.tar.xz...
<simonsouth> ghostscript-9.27.tar.xz 26.4MiB 110KiB/s 01:33 [###### ] 37.7%
<simonsouth>guix substitute: error: TLS error in procedure 'read_from_session_record_port': Resource temporarily unavailable, try again.
<simonsouth>substitution of /gnu/store/fdbjkcbw5n8qaf6asq4i6wqwj4hvdpl1-ghostscript-9.27.tar.xz failed
<civodul>thanks simonsouth
<civodul>"wget -O /dev/null https://ci.guix.gnu.org/nar/fdbjkcbw5n8qaf6asq4i6wqwj4hvdpl1-ghostscript-9.27.tar.xz" works for me
<civodul>could it have to do with the new GnuTLS fixup?
<civodul>hmm also works fine with wget + gnutls graft
<zalox>simonsouth: I'm also having problems
<civodul>this fails: ./pre-inst-env guix environment --ad-hoc guile3.0-guix -- guix download -o /dev/null https://ci.guix.gnu.org/nar/fdbjkcbw5n8qaf6asq4i6wqwj4hvdpl1-ghostscript-9.27.tar.xz
<civodul>crap
<simonsouth>civodul: That wget command works for me also now, on the same system.
<simonsouth>Ah.
<Parra>also I've discovered something strange, python asio tests don't pass
<Parra>because I was using fallback and I saw that
*civodul reports bug
<Parra>I imagine it is because of it tries to connect to internet or something
<civodul>actually it's not due to the replacement
<civodul>bah it works now
<civodul>ah no
<civodul>it looks random
<civodul>my ssh connection to berlin dropped out as well
<zalox>Yeah it looks random to me aswell. I tried to run guix pull three times in a row and the last time it worked.
<civodul>connecting over SSH took quite some time
<zalox>could it be under too heavy traffic?
<civodul>maybe
<anadon>Good morning guix!
<civodul>hey anadon!
<zalox>I'm pretty new to guix, is there a reason why you don't link to the issue tracker on your webpage?
<civodul>hi zalox, i think https://guix.gnu.org/contribute/ does, no?
<civodul>rekado: i confirm we have connectivity issues
<roptat>oh, I was going to report an issue with the substitute server too :)
<zalox>civodul: riiight. That was not super intuitive for me at least. I started looking under help.
<zalox>civodul: I'm not able to check now, cause it seems the entire site is down.
<rekado>I can visit the site :-/
<rekado>I’m asking to see some traffic logs
<civodul>it's intermittent
<zalox>rekado: Me too at the momemt. I couldn't 5 minutes ago.
<civodul>it's off-line for me right now
<rekado>yes, here too
<civodul>SSH as well
<rekado>my SSH connection is gone
<zalox>I think it's safe to say it's struggling
<rekado>the server seems fine though
<rekado>only three or four cores of 72 are in use; there’s plenty of free memory
<roptat>io?
<civodul>i killed "guix gc --list-dead" to reduce i/o before it went off
<civodul>rekado: do you happen to have the .onion address of berlin?
<civodul>seems i don't have it :-/
<rekado>I don’t
<rekado>could be MDC network problems
<rekado>people are now reporting problems connecting to other servers on the network
<rekado>I can’t connect to my workstation either.
<civodul>i had "make release" running but it just crashed badly because of that :-/
<rekado>probably MDC-wide network problems
<civodul>i need to add --fallback in the makefile
<rekado>oof
<rekado>just confirmed: “there’s a firewall issue”
<rekado>my old nemesis
<rekado>word is that someone started replacing switches in one of the data centres which made the firewall very unhappy
<rekado>they’re trying to fix it now
<rekado>I have to go for a few hours; hope this will be fixed soon.
<civodul>thanks for checking, rekado!
<civodul>i realized that now one could easily run Privoxy talking to Tor, and do "herd set-http-proxy guix-daemon http://localhost:8118"
<Kimapr>anyone has a derivation substitute for blender?
<Kimapr>everytime i try to build it my computer freezes
<mroh>this new switch/fw makes ci going up and down... we need ipfs substitutes ;)
<guix-vits>sneek: botsnack
<sneek>:)
<cbaines>has anyone see "mmap(PROT_NONE) failed" from Guile?
<civodul>cbaines: with libgc 8 as seen on core-updates, right?
<cbaines>civodul, I've been looking in to why the Guix Data Service can't process core-updates: https://guix-patches-data.cbaines.net/repository/2/branch/core-updates
<civodul> https://issues.guix.gnu.org/issue/36811
<cbaines>It seems that the inferior process dies while processing lint warnings/system tests
<civodul>cbaines: what's this:
<civodul>error: while processing ccl ignoring error: %exception: (#<&store-protocol-error message: "derivation `/gnu/store/sq74m3fny9fsh6v5jlipfhip9icp7j63-UNSUPPORTED.tar.gz.drv' has incorrect output `/gnu/store/xwvdjgz5i8s5z9gkl74nykg868fs4zxz-UNSUPPORTED.tar.gz', should be `/gnu/store/wj3g5z2wfx2f2d83dr8pahj8ldzk2aq5-UNSUPPORTED.tar.gz'" status: 1>)
<civodul>?
<roptat>civodul, I'll send a new tarball to the TP soon
<civodul>ah well, ccl
<civodul>awesome, thanks roptat
<cbaines>civodul, should match up with what you get running: guix build --no-grafts --system=armhf-linux ccl
<civodul>cbaines: rather aarch64-linux, no?
<civodul>according to the ccl definition
<cbaines>I get an error for both aarch64-linux and armhf-linux
<civodul>but then, ccl has a 'supported-systems' field, which the Data Service should honor
<civodul>oh right, i see that as well
<civodul>hmm
<civodul>wait no, "-s aarch64-linux" fails, but not "-s armhf-linux"
<civodul>same on master
<cbaines>This command seems to fail for me: guix build --no-grafts -d --system=armhf-linux ccl
<cbaines>I think the code in the Guix Data Service for working out what systems/targets you should be able to generate derivations for could probably be improved. I'm not quite sure what state it's in at the moment.
<cbaines>Back to the actual failure though, do you think the "mmap(PROT_NONE) failed" bit relates to a Guile issue?
<lprndn>Hey, just updated my lightdm service patches! (https://debbugs.gnu.org/cgi/bugreport.cgi?bug=35305#38) If someone is willing, I need some advices on how to deal with config files in /etc and directories in /var/lib...
<bricewge>I will review it again but it would be nice if a commiter could shime in
<cbaines>civodul, this is what I see from strace for the inferior process, in case that's informative: https://paste.gg/p/anonymous/25a536a289074a118c3d8bd6e58a138b/files/5d064a9209794913b1d017128812aa06/raw
<Kimapr>oof. tried to install blender again
<Kimapr>the whole system freezed
<Kimapr>and freezing seems to happen sometimes with heavy apps. Why is this possible? looks like a security hole or something
<bricewge>Kimapr: Which architecture and which revision of guix are you using (guix describe)?
<Kimapr>Generation 10 Apr 07 2020 16:21:17 (current)
<Kimapr> guix 3302e03
<Kimapr> repository URL: https://git.savannah.gnu.org/git/guix.git
<Kimapr> branch: master
<Kimapr> commit: 3302e03ba0edca49347c6a2b215e56bd53a6b113
<Kimapr>the issue is not unique to guix system
<Kimapr>this happens on other gnu/linux systems too
<Kimapr>(architecture = x86_64)
<mehlon>that might be because your system tries to compile it and then... yknow, freezes
<raghavgururajan>Kimapr You could try `guix package --install blender --cores=1`
<bricewge>Kimapr: There are some derivation available from 2 month ago http://ci.guix.gnu.org/build/2440971/details
<bricewge>I'm not sure how to get then though
<roptat>civodul, sent
<civodul>yay, thank you!
<bricewge>Is there a straight forward way to get a revision from a build ID of ci.guix.gnu.org?
<raghavgururajan>sneek, later tell ngz: Now sure you if you received my DMs as I am using XMPP-IRC bridge. I have sent the revision patches with suggested changes. :-)
<sneek>Will do.
<Kimapr>thanks
<civodul>bricewge: on Cuirass master the UI links builds to evaluations
<Kimapr>i'm trying the --cores=1
<civodul>bricewge: otherwise, through the JSON API
<civodul>like https://ci.guix.gnu.org/build/2549237
<civodul>hmm
<civodul>maybe not?
<civodul>oh it's not there, silliness
<bricewge>civodul: Yes it's absent, I tried to look trough data.guix.gnu.org but I wasn't successful there either.
<civodul>yeah data.guix.gnu.org is separate, but it should allow you to map to a commit ID
<civodul>it's much better in that regard
<civodul>cbaines: can tell you how :-)
<cbaines>bricewge, what are you trying to do in general?
<civodul>for me the use case is this: i find a build via the search box, and i want to map it to a commid
<bricewge>It looks like a good feature to have: look at the last available substitute, use ”guix time-machine” to install it
<civodul>*commit
<bricewge>Yes also
<civodul>bricewge: for that (guix ci) has enough, i think
<civodul>see the channels.scm that rekado posted one or two days ag
<civodul>*ago
<civodul>argh
<cbaines>bricewge, are you looking for substitutes for Guix itself (the guix-modular Cuirass spec), or a package in Guix?
<bricewge>cbaines: I'm looking for the last blender http://ci.guix.gnu.org/build/2440971/details for Kimapr
<cbaines>bricewge, This page http://data.guix.gnu.org/repository/1/branch/master/package/blender/output-history shows the outputs, and whether they've been built by ci.guix.gnu.org and bayfront.guix.gnu.org
<civodul>cbaines: we should build a (guix data) similar to (guix ci) and start playing with it
<civodul>we could build crazy tools
<cbaines>If you find the output you want, then look in the "To" column, and click on that date, that'll take you to the page for a revision with the commit hash
<cbaines>bricewge, and do change the system if your not on x86_64-linux
<cbaines>civodul, yeah, a Guile API would be cool :)
<bricewge>I'm looking thanks :)
<bricewge>Few times people requested to have a way to only use substitutes or be sure that all the substitutes they need are available before they “guix pull”, maybe such an API could help going in that direction.
<cbaines>I'm personally hoping we can get to a point where substitutes are generally available for everything. That'll take improvements is reliably and quickly building packages, as well as having less packages that don't build.
<raghavgururajan>bricewge me me me me me
<raghavgururajan>I am one of those people. ;-)
<civodul>bricewge: rekado posted a channel.scm for that (well, for substitutes of Guix itself), but i second cbaines
<civodul>but it's definitely usability problem #1
<bricewge>civodul: On IRC or the ML, I can't find it.
<civodul>bricewge: here's a previous iteration: https://paste.debian.net/1139368/
<civodul>we can adjust it to use (guix ci), lemme see
<bricewge>For sure it'll be better to achieve it as cbaines suggest.
*raghavgururajan ---> zzZ
<civodul>here's an updated version: https://paste.debian.net/1139371/
<civodul>should we put it in the cookbook?
<civodul>with a red bold warning
<bricewge>Wow, that's way less verbose. Nice!
<bricewge>At least on the cookbook it won't be lost in the logs.
<str1ngs>bricewge: substitutes would be really nice for lapatops and low powered computers. might be handy for having more stable rolling releases too
<str1ngs>substitutes only*
<bricewge>Kimapr: guix time-machine --commit=0f96fd645402f18bfe0ebeb4159e2daea8cad154 -- install blender
<bricewge>You'll get blender as a substitute on x86_64
<dattashantih8>Is there any easy way to setup cmake when using libraries from guix?
<sneek>dattashantih8, you have 1 message!
<sneek>dattashantih8, str1ngs says: . I was able to get guix-daemon to work with a rootless cgroup. Though that might not get around your user mapping issue. But it's progress atleast
<civodul>dattashantih8: in general, you should use all the tools from Guix
<civodul>so for instance "guix environment --ad-hoc cmake gcc-toolchain libfoo libbar"
<dattashantih8>civodul: Ok, I added gcc-toolchain, cmake, and all the libraries I need to a profile. But when I try to run the executable, it is unable to find any of the guix libraries.
<civodul>dattashantih8: you first need to build your executable using all these tools
<civodul>it's not enough to have them around
<lispmacs[work]>+1 for deprecate Linux!
*rekado is back
<rekado>is the network situation any better now?
<guix-vits>i did `guix pull` successfully
<rekado>cbaines: I don’t think with our current processes we *can* ensure that substitutes are always available.
<dattashantih8>civodul: Thanks, it was just user error. cmake was defaulting to using /usr/bin/cc instead of gcc from guix...
<rekado>the whole “push to master and then build” process ensures that we’ll always miss some substitutes.
<rekado>it’s also not about compute power
<rekado>we have that
<rekado>also not about reliability; issues like today’s network weirdness are very rare.
<rekado>it comes down to a change in processes
<str1ngs>dattashantih8: what was your user mapping issue? I'm able to user map but I wrote my initializing program in go and used syscalls
<dattashantih8>str1ngs: I do not remember. I was able to get everything working with charliecloud awhile ago.
<str1ngs>dattashantih8: gotcha, I remembered discussing this but it quite sometime ago. my program is used for another project and is like a very slim runc. Though I've been meaning to see if I can port it to scheme only.
<rekado>civodul: your channel snippet mentions berlin.guixsd.org, but I think we should avoid that name and use ci.guix.gnu.org instead.
*guix-vits "tja, %base-services changed. i'd asked for that" :)
<bricewge>rekado: By a change in processes what do you mean? Building before pushing to be sure that nothing break?
<dattashantih8>str1ngs: Yeah, I looked into using your program, but charliecloud was already installed on the machines I use.
<lfam>Ah, the IRC logs got reversed :)
<str1ngs>dattashantih8: makes sense
<str1ngs>dattashantih8: I think though it might be possible to use guix pack to. but I'm not sure if that support user mappings
<guix-vits>seems that there is no rotlog in base.scm?
<bricewge>guix-vits: Which one? Ludovic added it to %base-services in 0468455e7d279c89ea3ad1b51935efb2b785ec47
<rekado>lfam: I restarted goggles on bayfront
<rekado>I thought it would be restarted on reconfiguration but there’s no service for it.
<rekado>sorry for taking so long to apply the change
<lfam>No worries rekado
<lfam>Thanks for taking care of it
<guix-vits>bricewge: now i see it :)
<cbaines>rekado, yeah, that's one of the reasons I've been trying to work on automating parts of reviewing patch review. I'm hoping improving the process of reviewing patches will lead to less packages that don't build.
*guix-vits just after nscd-
<Blackbeard>Hello :)
<guix-vits>Hi Blackbeard.
<Blackbeard>guix-vits: how are you
<guix-vits>Blackbeard: good; how are you?
<Blackbeard>guix-vits: I am ok.
*lfam tests libssh security update
<lispmacs[work]>Hi, I was trying to create the hurd vm as described in the blog post, but forgot what I am supposed to do to get the ./preinstall-env script created. Just ./bootstrap, or was the more to it...?
<lfam>You need to build Guix from source, lispmacs[work]
<lfam>Check the first two sections of the manual chapter Contributing
<lfam> https://guix.gnu.org/manual/en/html_node/Contributing.html
<thomassgn>umm, anyone know which package contains the java runtime environment? like jar utility and similar?
<lfam>I think it's icedtea:jdk
<thomassgn>hah, yes indeed. Thanks :)
<rekado>thomassgn: JRE is just “icedtea” or “openjdk”
<rekado>JDK is in icedtea:jdk or openjdk:jdk
<rekado>hmm, looking again at my mumi code I actually don’t think debbugs should have had any problems with my requests.
<rekado>I passed the If-Modified-Since header for each request, so the server should have returned an empty body.
<rekado>all of these changes should have had the effect of considerably *decreasing* the load on debbugs.gnu.org
<rekado>previously we would fetch all messages independent of their age by using the SOAP service.
<civodul>perhaps it was just ignoring If-Modified-Since?
<rekado>maybe
<rekado>or mbox access is inherently slow / expensive
<rekado>dunno.
<rekado>I did test this before deploying it
<rekado>and If-Modified-Since did work as expected.
<rekado>I haven’t received any response to my messages to help-debbugs, so issues.guix.gnu.org remains broken.
<civodul>oh, it's broken?
<rekado>well yeah
<rekado>I had to turn off the updater
<civodul>it seemed to work well for me
<rekado>only old bugs since then
<civodul>ah so it doesn't see new bugs
<civodul>ok
<rekado>maybe I should give up mumi
<rekado>and offer a custom CSS for debbugs.gnu.org
<civodul>no no no, that doesn't sound right :-)
<civodul>yesterday we were full of hope and discussing a bright future without Perl!
<rekado>yesterday… all my troubles seemed so far away
<rekado>working with debbugs just seems to crash my mood. Gotta play with the hurd to cheer me up.
<civodul>yeah, good idea :-)
*janneke is all cheery looking at a failing gnutls cross build :-D
<civodul>so, i've been running "make release" +/- all day long
<civodul>and now the i686 image won't build because of course, the qemu test suite hangs
<janneke>oh my
<mbakke>have anyone experienced that (names with) non-latin characters display as question marks in GDM?
<mbakke>the same configuration works fine in `guix system vm`, though on the "core-updates" branch
<michel_slm[m]>howdy! thinking of trying out Guix - it warms my heart as a Lisper who also like Nix. if I'm virtualizing it (to dip my toes in) is there a preferred virtualization platform? e.g. KVM, VirtualBox
<civodul>mbakke: so the question marks are on master, right?
<lfam>michel_slm[m]: We officially support QEMU / KVM
<mbakke>michel_slm[m]: IIRC some users had trouble with VirtualBox, so KVM is the safest choice.
<lfam>It's built in to our tooling
<mbakke>civodul: I would guess so, building a VM there now to verify.
<civodul>ok
<civodul>i think i'll just turn off tests on i686
<civodul>for qemu
<lfam>And our manual has sections on Installing Guix in a VM and just running a pre-installed image in a VM
<user_oreloznog>michel_sim[m] I have used virt-manager
<user_oreloznog>for 1.0.1
<michel_slm[m]>awesome. user_oreloznog sadly Fedora is deprecating that -- I'll probably try GNOME Boxes (both use KVM underneath)
<emys>hi, I installed guix as described on https://guix.gnu.org/manual/en/html_node/Binary-Installation.html and would now use it as a normal user.
<emys>How do I set up my user's path variable?
<mbakke>emys: did you use the guix-install.sh script, or install manually?
<emys>manually, I didn't see the note right away about the install script
<civodul>roptat: BTW did you see the weird numbers and stuff during POXREF?
<roptat>yeah, but I don't know what it means
<mbakke>emys: you should configure your shell to source "~/.guix-profile/etc/profile", and afterwards add ~/.config/guix/current/bin first on PATH
<mbakke>the two profiles are unrelated; the first is where things you `guix install` end up; and the latter is where `guix pull` deploys the latest version of guix
<mbakke>probably the binary installation section should include a note about setting up the shell properly, hmm
<emys>mbakke, ok, but how are ~/.guix-profile and ~/.config/guix populated
<emys>maybe I should just delete the guix dirs and run the installer script
<mbakke>emys: no need for that, though you could take inspiration from the /etc/profile.d/guix.sh script it drops: https://git.savannah.gnu.org/cgit/guix.git/plain/etc/guix-install.sh
<mbakke>emys: you should run `guix pull` using the binary guix that you downloaded
<mbakke>emys: probably /var/guix/profiles/per-user/root/current-guix/bin/guix pull
<mbakke>it should work for your user too
<mbakke>that will create ~/.config/guix/current
<mbakke>then, with that in PATH, you have the latest version of Guix at your disposal
<mbakke>civodul: the QEMU test hang on i686 is weird, must be a new regression
<acakojic>Hello guys
<acakojic>installed guixOs on top of virtualbox
<acakojic>runned guix pull
<acakojic>and restarted
<acakojic>now after boot got this
<acakojic>New sessions c506 of user gdm. Removed session c506.
<civodul>mbakke: i remember noticing it a while back...
<acakojic>This is repeating all the time from c01 until 506
<civodul>i've pushed RC1 files: ipfs ls QmXpSUnppJgf23LpaKJzRWJbQxwEfybJy9VxF79iTLSXqa
*janneke wonders if it's a guile3 problem
<civodul>acakojic: it looks like GDM (GNOME Display Manager) is failing to start
<civodul>you installed 1.0.1?
<acakojic>cant enter gnome-shell login screen
<acakojic>maube guix pull done something wrong?
<acakojic>first time using guix system
<acakojic>installed it last night on virtualbox
<Blackbeard>acakojic: did you use the qemu image?
<mbakke>acakojic: so the initial install went fine, and then after guix pull and guix system reconfigure, GDM fails to start?
<acakojic>dont have support for qemu
<acakojic>guix pull; guix system reconfigure; last step: guix package -i guix-emacs
<acakojic>then reboot
<acakojic>this is my first time using this software
<acakojic>i can login
<acakojic>to profile
<mbakke>acakojic: can you see if there are any clues in /var/log/gdm.log ?
<mbakke>or maybe `sudo dmesg`, perhaps not enough memory?
<acakojic>ok, wait
<acakojic>dont have gdm.log
<acakojic>ups
<acakojic>got it
<acakojic>got greeter.log, 1 2 3 4
<civodul>mbakke, rekado: /admin/specifications shows a nameless spec :-)
<civodul>and http://ci.guix.gnu.org/specifications no longer works?
<rekado>huh
<rekado>that’s not right
<rekado>okay to remove the empty spec?
<mbakke>sure, no idea when or how that got there
<mbakke>remind me to have zabbix monitor the /specifications endpoint!
<rekado>hmm, can’t delete it because /admin/specifications/delete no longer exists…?
<rekado>oh, that’s because the URL is actually followed by the spec name… which is empty
<rekado>so gotta delete this manually
<dattashantih8>Is there anything I need to do to get shared libraries to work with clang from guix? It seems to work fine when I use guix g++ to link, but not when using clang++.
<mbakke>dattashantih8: are you using 'clang-toolchain' ?
<dattashantih8>mbakke: most likely not, I just did guix package -i clang...
<mbakke>dattashantih8: try 'guix package -r clang -i clang-toolchain'
***ChanServ sets mode: +o civodul
<mbakke>perhaps we should hide clang like we hide the plain gcc package
***civodul changes topic to 'GNU Guix | get Guix at https://guix.gnu.org | videos: https://guix.gnu.org/blog/tags/talks/ | bugs & patches: https://issues.guix.gnu.org | paste: https://paste.debian.net | Guix in high-performance computing: https://hpc.guix.info | This channel's logged: http://logs.guix.gnu.org | Test: https://lists.gnu.org/archive/html/guix-devel/2020-04/msg00172.html'
<madage>has anyone reported this error on building/upgrading guix build: error: `/gnu/store/5h0by98savzd9zv9nym7drr050pxm229-guix-1.0.1-15.0984481/bin/guix substitute' died unexpectedly ??
<madage>I see that there has been problems with the substitute server, but even with --fallback I'm getting this message since reconfiguring guix
<civodul>madage: there were networking issues earlier today with ci.guix.gnu.org
<civodul>though they seemed to be resolved
<civodul>does it still happen for you?
<madage>civodul: I don't know if it's related, but I'm still seeing the above error message, I'll try again
<joshuaBPMan>Hello, guix, I'm trying to get guix set up with Gnus and dovecot...
<madage>civodul: yeap, just got it again
<joshuaBPMan>does dovecot support fetching email from my email server? Or do I need to set up mbsync again?
<efraim>I don't think ham-radio needs qt-build-system imported
<mbakke>efraim: good catch
<mbakke>where did those patches come from? lots of co-authors but nothing on the lists, I guess Guix Days?
<efraim>not sure
<madage>full log of the error: https://paste.debian.net/plain/1139435
<mbakke>madage: what command are you running?
<civodul>also, is there anything printed before that?
<madage>mbakke: both guix package -u and guix build
<efraim>gnuradio was apparently sitting in the bug tracker for 2 years https://issues.guix.gnu.org/issue/31259
<mbakke>madage: what is your guix --version ?
<mbakke>efraim: woow :-)
<mbakke>efraim: woah, your response to my bug report has to be one of the fastest ever!
<janneke>hmm, i found (unless (getenv "GNUTLS_GUILE_CROSS_COMPILING") in gnutls.scm
<dattashantih8>hmm, clang-toolchain did not seem to fix the issue.
<efraim>mbakke: I'm sitting here refreshing my mail, deciding if there's anything I actually want to do
<efraim>:)
<madage>mbakke, civodul, this is what comes before: https://paste.debian.net/plain/1139436
<janneke>i can understand why its there; loading guile-gnutls-v-2 does not seem to work
<madage>when upgrading I get a message with the packages that will be upgrading
<emys>so, with guix environment it seems I can handily define my requirements/dependencies
<emys>is there a way to "lock" these?
*janneke ->zZzzz
<emys>for example if I want to be sure that I can run my code in the very same configuration in a week, when a new release of my dependencies has happened
<madage>config.scm is my guix system config, but I've been getting this message for a long time and previously it would proceed despite the warning
<cbaines>emys, I believe guix time-machine is the command you're looking for
<madage>mbakke: guix (GNU Guix) 543516ed0040df28eb15ea9b15ce905c038671c5
<mbakke>emys: see the '--root' argument of 'guix environment'. It can save a persistent copy.
<civodul>madage: why do you have /etc/gnu/*? sounds fishy
<mbakke>madage: the warnings about /etc/gnu/packages are weird. Can you try to "unset GUILE_LOAD_PATH" and run the command again?
<efraim>civodul: is './pre-inst-env guix build -f gnu/system/hurd.scm' supposed to hang for a long time before it starts to do anything?
<alextee[m]>still no meson 0.53 omg
<civodul>efraim: nope!
<civodul>could it be ci. networking issues?
<efraim>I tried with --no-substitutes
<civodul>ah
<civodul>hmm
<efraim>maybe I should've built with guile3.0-guix?
<civodul>built what?
<civodul>you're on wip-hurd-vm, right?
<efraim>yeah
<efraim>I mean configured that branch
<madage>civodul, mbakke: same error without GUIX_LOAD_PATH
<civodul>efraim: i don't think there's anything 3.0-specific in the "host side" code
<civodul>weird
<civodul>janneke just rebased the branch and we'll probably do so another time, so maybe it's in flux
<madage>I have it to define local versions of packages, mainly I use it to upgrade some packages before pulling and because two packages (ffmpeg and qemu) where refusing to build because of failures on tests run after compiling