<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 :| ***ChristopherParke is now known as Christ4
***Christ4 is now known as Christ6
***wshimmy_ is now known as wshimmy
<Blackbeard>I just, I want to contribute to emacs and it is so nice to be able to do <raghavgururajan>guix-vits Intresting and weird. I am confused for not having seg fault. xD <raghavgururajan>sneek, later tell bricewge: For xfe, I have sent v2 patch to #40487. <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. <xelxebar>brendyyn: Thanks. Crafting a bug report now. The --debug flag is helpful <sneek>Welcome back bricewge, you have 1 message! <sneek>bricewge, raghavgururajan says: For xfe, I have sent v2 patch to #40487. <bricewge>I didn't know there was that many people with commit access though <str1ngs>I just send my patches, and eventually when someone has time they look at them :) <str1ngs>I really need to find some to replace xcape . which does not work with wayland. <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 ***apteryx_ is now known as apteryx
<str1ngs>guix-vits: I still have not found a replacement for xcape in regards to sway. <bricewge>It uses uinput to inject key press. I bever used it though <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. <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. <str1ngs>bricewge: I think I can get kmonad to work. thanks ***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. <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. :) <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>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? <numerobis>bricewge: amazing, thanks. I assume you didn't browse the log page by page? <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>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:) <str1ngs>PlasmaStrike one nice think about kmonad is it works from console <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>kondor: from my point of view, their "business model" of substitution of advertising is illegal. <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: 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 <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]>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 <guix-vits>damo22: git of project X have a target "check" in it's Makefile; `guix build X` will run the `make check`. <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 <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 <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>one of my colleagues wanted to use it with Guix <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 <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 <rekado>damo22: everything ends up in /gnu/store <rekado>marmulak: shepherd provides halt and reboot. <rekado>“halt” is for a proper shutdown <marmulak>I've done halt before but the machine shut off so fast I thought maybe the system was not shutting down nicely <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>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 <rekado>damo22: you might like the work that has been made to implement an ever smaller bootstrap in Guix <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... :/ <xelxebar>Hehe. No worries. The build was failing already anyway, so it's good to know that --debug is dangerous. <civodul>for "POXREF doc/guix-cookbook.de.texi" <gfleury>i need pod2man in my build environmnent <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 <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>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>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? <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. <Parra>it seems like Guix CI is failing, did anyone experience it? <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>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> 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>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 <simonsouth>civodul: That wget command works for me also now, on the same system. <Parra>also I've discovered something strange, python asio tests don't pass <Parra>because I was using fallback and I saw that <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>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? <zalox>I'm pretty new to guix, is there a reason why you don't link to the issue tracker on your webpage? <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’m asking to see some traffic logs <zalox>rekado: Me too at the momemt. I couldn't 5 minutes ago. <zalox>I think it's safe to say it's struggling <rekado>only three or four cores of 72 are in use; there’s plenty of free memory <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? <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>just confirmed: “there’s a firewall issue” <rekado>word is that someone started replacing switches in one of the data centres which made the firewall very unhappy <rekado>I have to go for a few hours; hope this will be fixed soon. <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 ;) <cbaines>has anyone see "mmap(PROT_NONE) failed" from Guile? <civodul>cbaines: with libgc 8 as seen on core-updates, right? <cbaines>It seems that the inferior process dies while processing lint warnings/system tests <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>) <roptat>civodul, I'll send a new tarball to the TP soon <cbaines>civodul, should match up with what you get running: guix build --no-grafts --system=armhf-linux ccl <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>wait no, "-s aarch64-linux" fails, but not "-s armhf-linux" <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? <bricewge>I will review it again but it would be nice if a commiter could shime in <Kimapr>oof. tried to install blender again <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> commit: 3302e03ba0edca49347c6a2b215e56bd53a6b113 <Kimapr>the issue is not unique to guix system <Kimapr>this happens on other gnu/linux systems too <mehlon>that might be because your system tries to compile it and then... yknow, freezes <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. :-) <civodul>bricewge: on Cuirass master the UI links builds to evaluations <civodul>bricewge: otherwise, through the JSON API <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 <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>bricewge: for that (guix ci) has enough, i think <civodul>see the channels.scm that rekado posted one or two days ag <cbaines>bricewge, are you looking for substitutes for Guix itself (the guix-modular Cuirass spec), or a package in Guix? <civodul>cbaines: we should build a (guix data) similar to (guix ci) and start playing with it <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>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. <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>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 <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 <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 <rekado>is the network situation any better now? <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>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: I think though it might be possible to use guix pack to. but I'm not sure if that support user mappings <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>Thanks for taking care of 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- *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 <thomassgn>umm, anyone know which package contains the java runtime environment? like jar utility and similar? <lfam>I think it's icedtea:jdk <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>or mbox access is inherently slow / expensive <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. <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. *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 <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>i think i'll just turn off tests on i686 <lfam>And our manual has sections on Installing Guix in a VM and just running a pre-installed image in a VM <michel_slm[m]>awesome. user_oreloznog sadly Fedora is deprecating that -- I'll probably try GNOME Boxes (both use KVM underneath) <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: 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>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 <mbakke>acakojic: so the initial install went fine, and then after guix pull and guix system reconfigure, GDM fails to start? <acakojic>guix pull; guix system reconfigure; last step: guix package -i guix-emacs <acakojic>this is my first time using this software <mbakke>acakojic: can you see if there are any clues in /var/log/gdm.log ? <mbakke>or maybe `sudo dmesg`, perhaps not enough memory? <civodul>mbakke, rekado: /admin/specifications shows a nameless 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 <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 <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>where did those patches come from? lots of co-authors but nothing on the lists, I guess Guix Days? <mbakke>madage: what command are you running? <civodul>also, is there anything printed before that? <madage>mbakke: both guix package -u and guix build <mbakke>madage: what is your guix --version ? <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 <efraim>mbakke: I'm sitting here refreshing my mail, deciding if there's anything I actually want to do <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? <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? <efraim>maybe I should've built with guile3.0-guix? <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>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