<lfam>sneek: later tell efraim: mesa from core-updates built for me on x86_64 <efraim>lfam: thanks. I'll have to figure out why its failing to find libdrm on aarch64 <sneek>Welcome back efraim, you have 1 message. <sneek>efraim, lfam says: mesa from core-updates built for me on x86_64 <efraim>I removed i915 from the gallium drivers and configure passed, so its only libdrm_Intel that's causing my proplem <efraim>lfam: does libdrm on x86_64 build libdrm_freedreno? <efraim>So aarch has freedreno and no Intel, Intel platforms the opposite <efraim>I'll check what people have and prepare a patch today <ryanwatk`>Hi guys, I would really like to define an 'emacs server' service for a guixsd machine of mine, I presume it is doable somehow in the OS definition, does anybody have any idea how it would look? Should I look to the shepherd manual? <ryanwatk`>Likewise, I figured some screen sort of daemon service would also be nice. My home environment involves many systems so I wanted to offload a lot of system resources to the non embedded devices :D <rekado>efraim: is there a way to build the mesa drivers in a separate package? <efraim>rekado: possibly, but I think (match (%current-system) ... is the best option, this way everyone gets the drivers that they can actually use and its all in one package <efraim>currently we already drop the i915 dri-driver for non-intel systems, this just extends it for all the architectures and for the gallium-drivers too <efraim>on aarch64 libdrm provides amdgpu, freedreno, nouveau, radeon, vc4 and kms <snape>ryanwatk`: you should search for "normal user" in the shepherd manual <sneek>snape, wingo says: please do! <wingo>heh, i think that was about pushing your patches <rd161616>Previously I used qemu with the kvm option to run really fast and performant virtual machines, do you know how I can do it in guixsd please ? <snape>rd161616: --enable-kvm doesn't work? <rd161616>Well I have my barebones system with a few packages installed so far and IAM happy about it but i don't know which package i should install for qemu kvm snape <snape>rd161616: "qemu" package should be enough, according to its documentation <rd161616>Thanks mate, u think I'll be able to use the internet on it without too much problems ? <snape>I think you won't have more problems than with standard distros :p <rd161616>Also I don't have X11 installed is it a problem if I need windows 7 virtually <snape>But I don't know for sure, because I never used qemu on GuixSD directly <snape>I don't think X11 is a problem <rd161616>Or does it use the frame buffer directly <efraim>I can probably combine mips and _ since mips i believe can build i915 <ryanwatk`>snape: thanks, I will take a look, I am just watching the fosdem talk now about composing system services <ryanwatk`>another problem I seem to be getting is geiser and guile/guix integration, it keeps saying I should M-x run-geiser and when I do, no documentation is available from the original buffer <snape>ryanwatk`: maybe geiser can't guess your scheme implementation <snape>you can eval geiser-impl--implementation in a scheme buffer, to check it is guile <snape>I had a similar issue: I had to set geiser-active-implementations to '(guile) <snape>so to force geiser to use "guile" implementation <snape>Actually, without (setq geiser-active-implementations '(guile)), every scheme file with the word "use" is considered a Chicken file <snape>(Chicken is another scheme implementation) <snape>even though I run "run-guile" <snape>it might be a geiser bug, don't know <jmd>Is there a way one can persuade the guix daemon to continue a build which has aborted for some reason? <ryanwatk`>snape: setting scheme to guile gave me some documentation but I am seeing ludo has an emacs mode of Scheme Guix Guile, is that an additional emacs mode for guix devs? <thomasd>ryanwatk`: could be “guix-devel-mode”, part of package emacs-guix <jmd>civodul: From which checkout was that build done? <jmd>That one doesn't include lfams latest python fixes. <jmd>ACTION wishes that he understood how to use and interpret the hydra.gnu.org website. <efraim>i'm also going to trigger an nss rebuild on core-updates, aarch64 also needs the USE_64 flag <civodul>efraim: the mesa thing sounds good, it might not even trigger a rebuild on x86_64/i686, does it/ <efraim>it moves the dri drivers higher up so it'll cause a rebuild <efraim>but its on core updates so its not really a big deal <rekado>ryanwatk`: if you have a different URL for that package you could download it with Guix, which adds it to your store. <rekado>then Guix wouldn’t have to try to find it at the upstream URL. <ryanwatk`>rekado: unfortunately, guix package -i wireless-regdb is still fetching this url, I presume I can get the tar from elsewhere and install from file right? <ryanwatk`>rekado: so I changed the url manuall and did a guix package -f but somehow it still thinks I do not have the package :( <rekado>ryanwatk`: have you tried to do “guix download the-new-url”? <rekado>if the file has the same hash and the same name I suppose it would just work. <ryanwatk`>rekado: I did not know the command, I got it working by making a temp scheme file with the url replaced it seems, guix download sounds much easier though, thanks <jmd>What's the next big thing for Guix? <rekado>jmd: didn’t you ask this question just a few days ago? <rekado>I think it hasn’t changed since then. <rekado><jmd> [20:08:22] What's the next big thing in Guix? <rekado><lfam> [21:28:17] jmd: I'd say a better mechanism for updating Guix, and then <jmd>rekado: You keep a searchable index of everything said on #guix? <rekado>no, it’s just the ERC buffer on my workstation <jmd>Wow. It's bigger than mine. <thomasd>about the update mechanism, an option to update to a version for which substitutes are available, would be nice (at least some point, maybe we'd need more build infrastructure to make that work well?) <thomasd>this is probably obvious, but I haven't read the remark anywhere else, so thought I'd mention it anyway :) <thomasd>I wonder how others deal with substitutes and updates? I look which commits have been evaluated on hydra.gnu.org, checkout one of those in git, and upgrade from that. <rekado>I just upgrade to the latest version unless a kernel update had just been pushed. <efraim>er, only really supoprted *on mesa* on x86/x86_64 <roelj>Damn.. how long do these nss tests take? It's been running for 2 hours now.. <efraim>it took 3.5 hours on my 2007 laptop, 6 hours on aarch64 <roelj>Thanks for an estimate :). Can we do something about this (reduce the repetitiveness of the tests)? <roelj>Or is there a specific reason it needs to do things about a million times? <efraim>i checked the source, parallel builds aren't supported, we override 'check so I don't think its multithreaded ATM <catonano>I just reviewed a patc that had been reviewed already. Can anyone point me to an introduction about how to use tags in the Debbugs-Emacs thing ? <efraim>do we have a package with a conditional input that I can use as an example? <catonano>if a patch ahs been reviewed and is waiting for a reaction by its author. Is there a flag for that ? <rekado>catonano: I’d also like to know the answer to this question. <rekado>I think it may be something for which we have to find an accepted procedure. <civodul>efraim: in that case we could make the dependency on llvm conditional on x86 <civodul>most likely people on arm/mips don't care that much about mesa anyway :-) <efraim>civodul: that's my plan, i forgot the syntax though :) <rekado>civodul, efraim: doing so would also address Mark’s concerns. <efraim>and I was worried about being able to build llvm <efraim>on a similar vein, mysql failed after 7 hours to massive test failure due to lack of CPU time & RAM shortage <efraim>ok, i have mesa using llvm on for x86_64-linux and i686-linux, and not using it otherwise <catonano>in a normal debugger "pending" would mean that the buug has not been triaged yet <catonano>it could mean that it is waiting for the author to react to thhe review <catonano>in the debbugs web interface I see there are 5 bugs markes with "More information needed" <catonano>were they manually markked by someone ? Or are they automagically classified by an algorithm run by Debbugs ? <wingo>manually tagged "moreinfo" i think <rekado>do you know how to display only those bugs that were assigned to me? <rekado>I’m still struggling with debbugs-gnu-search ***chatter is now known as Guest9305
***Guest9305 is now known as chatter29
<civodul>catonano: most likely i added the "moreinfo" tag <civodul>rekado: i don't think bugs can be assigned to people, can they? <catonano>civodul: so when you mark them with "more info" do you mean that you asked the author to please send a reviewed patch ? <rekado>civodul: they can. I just hit “C” and then “owner”, which sends a control message to assign the bug to myself. <civodul>catonano: yeah, that or, if it's a bug, means we need more info to act on it <rekado>oof, fixing R reproducibility issues is hard :( <rekado>actually, fixing *any* reproducibility issues is hard, as a rule <rekado>in R timestamps and mtimes end up in generated files, but the Makefiles are pretty hard to follow. <rekado>I just don’t know what rule executes a piece of code. <rekado>it’s an R snippet that’s run at build time; if I remove handling of timestamps there I might actually break runtime code, so I’m trying to find a way to just reset the mtime of generated files right before the code is run. <rekado>it’s an unfortunate downside to code reuse. <rekado>could this make bootstrapping scala easy? <bavier`>is the java-based scala difficult to bootstrap? I've probably missed the discussion. <civodul>rekado: not as exciting as Guile 2.2 :-) <civodul>though that fixes a serious shortcoming of Scala IMO <wingo>civodul: how long will it take guix to switch to 2.2, do you think? <wingo>i guess it can do either when you build from source <civodul>wingo: i'm using it on 2.2 since a few days <civodul>there are still a couple of test suite failures that i need to investigate <civodul>as for using 2.2 in derivations, that could happen on the next core-updates <civodul>switching packages to 2.2 by default will be easy, most of them already work with 2.2 <wingo>i will try to upload a 2.2.0 tarball somewhere tonight <civodul>i'll have 'guix pack' things for you to test <wingo>should give us enough time to try "guix pack" before blessing the tarball on thursday <wingo>ACTION updating guix on laptop <wingo>nss sure takes a long time to build <rekado>bavier`: the JVM-based Scala cannot be bootstrapped. <rekado>to build a release from source you need to have a pre-built development version of Scala. <rekado>this goes all the way back to the origins of Scala. <snape>wingo: after nss, there is icecat... <bavier`>so now we might be able to use the native compiler to bootstrap the jvm compiler <[df]_>dependencies on the java standard libs might be a problem <rekado>the native compiler comes with implementations for some of the libs, but I suspect it isn’t yet comprehensive enough. <bavier`>and scala-native uses sbt for its build <bavier`>yup, I don't see any other build system files <rekado>I find this sad: “*To contribute to this code, it is strictly forbidden to even look at the source code of the Oracle JDK or OpenJDK!*” <rekado>“This is for license considerations: these JDKs are under a GPL-based license, which is not compatible with our BSD 3-clause license.” <bavier`>why not prohibit contributors from reading any gpl'd code? /s <rekado>hmm, the thing is written in Scala, so I think one would really need to have the JVM Scala first. <wingo>snape: yay indeed, there is icecat :) <ryanwatkins>but wnat about if they think about the gpl licence source code, I think it is high treason <lfam>High treason is usually a capital offense. But, at least they'll give you a cup of Java first... ;) <civodul>there'll be 2 repro build talks at LibrePlanet! <lfam>ACTION basks in the thunderous laughter and applause <civodul>wingo: so now you can do things like: "guix pack guile-next --symlink=/opt/gnu/bin/guile=bin/guile" <efraim>wingo: guile-2.1.8 built in about 6 hours on my aarch64 board <bavier`>rekado: I just found your writeup on bootstrapping haskell. good read. <bavier`>rekado: btw, do you know whether the "logo" image on bootstrappable.org is truncated on the right, or is that how it's supposed to be? <wingo>efraim: cool. hopefully with that recent gc patch that went in after 2.1.8, that time should go down too <jmd`>It seems that bash or one of it's dependencies has recently changed in master. Shouldn't that have been pushed to staging/core-updates ? <lfam>What do you see that makes it look like bash was changed? <efraim>there was the CVE that required rebuilding an early bash version for grafting <jmd`>efraim: Oh maybe it is only a graft. ***jmd` is now known as jmd
<jmd>What is the stdin of the guix daemon? <jmd>It looks like the python entropy fix didn't work :( <efraim>mesa and nss fixes for aarch64 pushed to core-updates! <jmd>Where can I get a aarch64 machine to try it? <efraim>its about $50 for the board, just needs a microSD card, power from usb and an ethernet cord <buenouanq>have you preordered your eoma68 libre tea boards yet #guix? <jmd>efraim: I've heard it'll fit the same enclosure as a RAspberry pi is that correct? <efraim>dunno, I have mine just sitting out on top of an external harddrive <efraim>i don't know if the ports would line up <joshuaBPMan_>Hello, is there way I can make simple guile games? maybe something that'll run in the browser? <bavier`>buenouanq: put in my order a long time ago <buenouanq>joshuaBPMan_: watch the SICP lectures and get hacking <buenouanq>browser things are going to be a level removed, but there is a guile web server <buenouanq>you should maybe find a guile specific room for this though <buenouanq>And I can add multiple instances of this (with different configs, ports, etc) to my OS config yeah? <efraim>i notice our ibus package doesn't have wayland support, or emoji support <lfam>I'm going to try building it locally. Hopefully it's a transient error <civodul>lfam: it definitely looks like a transient error <civodul>those seem to happen frequently these days :-/ <lfam>Okay, I've restarted it on Hydra. I'm still building it here, too <civodul>this build exited with code 100, which is normally for permanent build failures (per offload.scm) <lfam>I can build python@3.5.5 on x86_64 for the i686-linux system <civodul>sounds like we need to restart dependency-failed builds <lfam>Well... doing. Hopefully the HTTP request goes through <rekado>bavier`: I can’t reproduce the logo truncation error in icecat :( <thomassgn>my laptop keeps crashing during some of the heavier builds due to overheating. I've added max-jobs=1 and cores=2. The laptop is an hp elitebook i7 4G ram and I have been running both nixos and gentoo (everything compiled) fine earlier. I find MCE messages in my logfiles, but can't make much out of them. Any tips for checking build daemons current settings or getting more info from MCE/Kernel? <civodul>thomassgn: i have the same laptop running GuixSD but i haven't seen this <civodul>to check the daemon's settings, just just "ps aux | grep guix-daemon" and look at the command-line optinos <lfam>optinos are the atomic configuration particles that compose the daemon's configuration files ;) <luser1>civodul: I was the person who had the corrupted ssd yesterday you helped. Wanted to say thanks :) <thomassgn>so guix daemon starts 2 instances with 1 core each. as expected. Don't understand why this makes it overheat... ***the_ktosiek is now known as ktosiek
<civodul>thomassgn: BTW, i'm curious how you managed to install GuixSD on that laptop <civodul>it requires UEFI, which is undocumented :-) <thomassgn>civodul: mine is an old one (I think 6 or 7 years old by now). so UEFI is optional, I've turned it off. (: <lfam>Does it crash if you just load the processors with useless work? <lfam>Like, running `yes > /dev/null &` per-core? <lfam>thomassgn: I guess there's no need to try if the MCE messages specify an overheating condition. <lfam>Anyways, that's how I warm up cold laptops ;) <thomassgn>lfam: haha, nice. I think it's overheating, but I haven't been able to pinpoint much, I don't even know what happens at boot in my logs so the messages from MCE may be unrelated. But I just started the MCE daemon manually (didn't look like it was running from 'sudo herd status'). Am retrying to build system; as there now is a new mcelog file in /var/log/ .... <buenouanq>man, just as I mentioned the EOMA68, it gets pushed back a couple months (;-___-) <buenouanq>efraim: I've yet to successfully get ibus working on GuixSD at all... <lfam>buenouanq: Does it work when you try it? <buenouanq>I haven't gotten that far yet - I'm really just asking about the service declaration syntax I think. <lfam>I haven't used that service but presumably you want those fields to have a value besides "" <buenouanq>manual has some with and some without quotes, but can they all be quoted? <buenouanq>I'll fill them in when I better know what I'm actually doing <buenouanq>I think some of these too I might want to leave off and just let the postgres config deal with them <lfam>Maybe you'll have to use --cores=1 <thomassgn>civodul: mcelog --daemon creates this file /var/log/mcelog <buenouanq>So, I have a postgres service running, but this obviously didn't install all the tools (things every tutorial mentions) I need to access it from whatever user. In addition to the service, am I supposed to install the postgres package under said user? 