<Veera>I installed mate only but gdm only shows login screen but does not logs in when I enter password. It just comes back. <Veera>So I installed mate + gnome. And now it logs in to gnome. <Veera>I want to know how to give an option to gdm so that I can login and use mate also <lfam>Veera: Did you add the mate-desktop-service-type your config.scm? <Veera>I read Xorg services page and it says I need to put xsession file. <Veera>In that path there is gnome.desktop and mate.desktop file. <lfam>Does MATE show up in the menu of GDM? <Veera>Just shows my user: net and password entry <lfam>There is something you can click on that is a menu <lfam>I forget what it looks like <Veera>Above top right corner there are. But none shows a option for that. <nixo_>Hi guix, do any of you got some games working on guix on an x200? I think my setup is wrong because xonotic runs at 15/20fps <nckx>nixo_: That doesn't sound implausible to me. Xonotic is not a lightweight game. <nixo_>nckx: every setting is at its minimum. Also the window size <brendyyn>nixo_: have you used xonotic with another distro with better frames? <nckx>OK, that's a bit much. Which CPU do you have? I think I have a very similar machine and can give it a try. <nixo_>vblank_mode=0 glxgears: 270FPS (I'm reading on forums that it should be 1000+ on this laptop) <nckx>I'll give Xonotic a try in an hour or so, stock settings. <brendyyn>i only get 700KiB/s from the guix ci so it takes time to download <seepel>So far I'm absolutely loving Guix System, but I'm still a bit confused about shared libraries, I seem to be able to muddle through sometimes, but not others. For example node is looking for libstdc++.so.6 And I have no idea how to let it know how to find it. Is there maybe a page in the manual that I missed? <nckx>Unless you find the enlightenment in the meantime đ <nixo_>should mesa-opengl // xf86-video-intel // anything else installed? or some xorg config that I might be missing <nixo_>nckx: thanks, I'm reading everything I can find, I'll report back how it goes <brendyyn>are you running guix on a foreign distro? <nckx>nixo_: I use xf86-video-intel. Xonotic wouldn't run without mesa, it's an openGL game. <seepel>brendyyn: Not sure if you are asking me, if so, no I am running Guix System <nckx>nixo_: You can look at /var/log/Xorg.0.log. If the Intel driver is loaded and working it's quite obvious, lots of intel(0)⊠lines and âswitch to modeâŠâ as one of the last. <nixo_>cat /var/log/Xorg.0.log| grep intel | wc -l : 1 <nckx>(I'm sure there's a much better âwhich driver am I using?â command but I don't know it.) <nckx>nixo_: So which driver is used? <nckx>%default-xorg-modules includes xf86-video-intel (as well as⊠everything else), so unless you've customised your xorg-configuration it's available. You could force it with (drivers '("intel")) but that should not be necessary. <nixo_>egrep -i " connected|card detect|primary dev|Setting driver" /var/log/Xorg.0.log -> modeset <nixo_>in my xorg-configuration I just added (keyboard-layout (keyboard-layout "gb" "extd")) <brendyyn>is there a difference between xonotic-sdl, glx, dedicated? <nckx>nixo_: Try with (drivers '("intel")) but be prepared to roll back. <nixo_>brendyyn: don't know, tried xonotic + xonotic-glx but they seem to behave the same way <nckx>brendyyn: -glx uses GLX (X's GL extensions), -sdl uses the SDL game/utilitily library (99% likely that just uses GLX to do the rendering), -dedicated is a headless server. <nckx>You can remap your keys. <brendyyn>on windows, many games often automagically detect your layout and set wasd accordingly <nckx>Meh. That's trivial to do. It's the games that don't bother. <nckx>Shame they don't but no standard needed. <nckx>But interesting, I didn't know that was a thing đ <nixo_>nckx: loads the display manager and freeze <sneek>nixo_, nckx says: I forgot to ask you for a paste.debian.net copy of you Xorg log. Oh well. <nckx>nixo_: That's more than I expected! So the intel driver can show you pixels, at least. <nckx>Did the failed boot save a Xorg.0.log.old? <nckx>It might tell us more and should look quite different from the modesetting one. <nckx>OK, yeah, say hello to the worst of the drivers. <nixo_>the forced intel didn't save anything <nckx>You won't be doing much 3D on that. It's almost impressive your poor CPU can fill your screen 20 times a seconds by thinking alone. <nixo_>this cpu is impressive, btw. Considering it's 12 yo <nixo_>Comments on %default-xorg-modules say: the first one in the list is loaded. <nckx>Yeah, the P8400 is still⊠OK. Considering the nightmare that is the modern Web. It falls on its face when Skyping though (don't yell at me; not my machine). <nixo_>and fbdev comes in the second place <nckx>nixo_: You can certainly try (modules '(xf86-video-intel <your input driver>)) but a) it requires knowing your input driver (mine's libinput) and b) setting (drivers '("intel")) should be equivalent. <nckx>âShouldâ being a magic word where computers are concerned, but still. <nckx>nixo_: I'm afraid I can't really help you much further, since I don't own an actual X200. I hope finding the root of the problem was helpful đ Xonotic is innocent. <nixo_>may it depend on the display manager? I moved 2 days ago back to slim <nckx>nixo_: I doubt it but won't make any pronouncements on a system I've never owned. <nixo_>nckx: thank you very much for your efforts <nckx>If you'd said âmoved to GDM last week, now graphics are borkâ I'd believe you. <nckx>Other way 'round, unlikely. <nixo_>never tryied playing video games on this until today <nckx>People sometimes underestimate Xonotic (yes, it's 90s Quake, but gutted beyond recgnition) but it should deffo be playable at sane settings. <nckx>nixo_: Your computer is saving you from yourself. <nixo_>I realized it was a problem after trying minetest, too. It's way worse than xonotic, performance-wise <nckx>âŠwe have Dooms, I guessâŠ đ€· <brendyyn>with Godot, we can expect more good free software games i think <drakonis>godot existing does not imply more free software games <drakonis>it does imply more games made with free software <drakonis>its advantageous as it can replace unity <nckx>drakonis: Oh, I adore Doom. I'd just rather nixo_ have more choice. <drakonis>let me see what else's good and fun, the breadth of roguelikes <nckx>I wasted too much time on Hyperrogue this week đ <drakonis>doom eternal is out soon but sadly its proprietary <nckx>Wesnoth is nice and (to an outsider to the genre at least) polished and has a lot of downloadable campaigns. <drakonis>devilutionx is a thing if you're into diablo <drakonis>wesnoth is fairly well polished but it is combat centric <drakonis>if only it was like heroes of might and magic <nckx>drakonis: Is Devil⊠in Guix? <nixo_>glxgears on another x200 with xubuntu is.. slower <drakonis>i find myself inclined to agree with a off channel comment that guix needs its ubuntu <drakonis>it currently caters to a narrow range of use cases <brendyyn>guix is not just a distro but a tool for building distros. i hope in the future the idea of a distro will become synonymous with a guix operating-system specification. <drakonis>guix, much like nix, is a means to composing systems <alextee[m]>nckx: a non-free OS that doesn't let you shut down until it finishes installing its upgrades <brendyyn>it often gets very low frames but its fun <nckx>I've tried playing it before but I never managed to have fun. <nckx>Not a dig at 0ad, I probably stopped right before it started. <brendyyn>i think its not as good as age of empires unfortunately <brendyyn>but maybe thats just my childhood nostalgia talking? <brendyyn>how can you make an AoE clone and not have trebuchets. <nckx>Anyway, the point of Guix is to build a free software distribution. The last thing it âneedsâ is for someone to ruin it by reverting back to a proprietary mess. <nckx>I will actively wish that project harm an failure because it is harmful and unethical. <brendyyn>indeed. i hope we can maintain a free software majority <brendyyn>otherwise all the time is wasted, i may as well have just developed nixos <drakonis>eh, seems like a waste to see nixos as just the proprietary parts <brendyyn>i realised i cant minimise xonotic in sway while its playing <nckx>I feel like I've missed something by never playing AoE. <nckx>Been here since forever. <nckx>Last talked in June 2019. <Veera>I installed mate only but gdm only shows login screen but does not logs in when I enter password. It just comes back. <Veera>So I installed mate + gnome. And now it logs in to gnome. <Veera>I want to know how to give an option to gdm so that I can login and use mate also <Veera>I read Xorg services page and it says I need to put desktop file in xsession dir. <Veera>In that path there is gnome.desktop and mate.desktop file. <Veera>The gdm is not showing any menu option to select between the two <nckx>Veera: No cog wheel (â) next to the âLog inâ button? <nckx>(It's been years since I've used GDM, but it used to exist.) <nckx>Veera: I use Slim (slim-service-type). That's not a recommendation, just a fact. <Veera>in xsessions directory there is also a file named gnome-xor.desktop pointing to gnome.desktop <apteryx>rekado_: I'll let you know when I get around to running the nfs system test. It may be broken the same way as the install tests (no clue yet as of why, just know the breakage has to do with updating Shepherd to 0.7.0). <apteryx>(I ran an expensive git bisect to learn this) <brendyyn>(string-append (assq-ref %guile-build-info 'top_srcdir) <brendyyn>(string-append (assq-ref %guile-build-info 'top_srcdir) <brendyyn>$4 = "/tmp/guix-build-guile-2.2.7.drv-0/guile-2.2.7/module/language" <brendyyn>naturally thats a temporary directory that doesn't exist anymore <apteryx>eh, seems you answered the question :-) <guix-vits>Can be started just from console, without a DM. <guix-vits>Blackbeard: theme is about the shepherd, right? <guix-vits>about the first question, i even can't answer, btw. feels normal. <guix-vits>brendyyn: i'm just tried `guix --pure --ad-hoc qutebrowser -- qutebrowser` -- fonts are there; not sure if this matter anything, as Chromium possible has a built-in fonts. <guix-vits>Got 2 error: "WARNING: QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-guix-vits'" <bavier`>Blackbeard: good luck with the application <guix-vits>Blackbeard: all people have a bugs in their genetic code: relax and not take anyone seriously. <g_bor[m]>After running make check I noticed that one test pollutes the services directory with a testresult file. <g_bor[m]>I believe either the result file be gitignored, or the test fixed somehow. <g_bor[m]>I would also propose to gitignore top level directories beginning with t- but that would mean to reserve these directory names. <raghavgururajan>g_bor[m]: Would you be able to create a new public mail list for internships(outreachy+gsoc)? Like guix-projects@gnu.org or guix-internships@gnu.org? <sneek>Welcome back raghavgururajan, you have 1 message! <sneek>raghavgururajan, guix-vits says: <3 :P <raghavgururajan>g_bor[m]: Okay. Thanks. I would like to start a mail list thread asap. <g_bor[m]>Sorry for the delay, I know that you have already requested this. <g_bor[m]>It might take some time as I believe that mailman instance is not managed by us. <guix-vits>g_bor[m]: are Veera 've catched you there in the end? <g_bor[m]>ok, I now have the exact filename: tests/services/linux.trs <Veera>I had issue with mate desktop. I solved it. <Veera>One thing as outreachy contributor; do we have to package new ones or if update the old pkg is enough <g_bor[m]>Veera: I believe packaging a new one would be better. I say this, because updates are often trivial, and sometimes very difficult. <g_bor[m]>Packaging might also be very difficult, but for example packaging something R from cran using the importer is very simple. <efraim>sneek: later tell civodul any suggestion where I should add the fontconfig filesystem? I was thinking (gnu system file-systems) next to elogind but I wasn't sure if that was better than (gnu services desktop) <g_bor[m]>efraim: (gnu system file-systems) looks better to me. But let's wait for civodul. <guix-vits>efraim: i'm use only %base-services; can it please go to %base-file-systems ? <g_bor[m]>sneek: later tell civodul What would it take to get an internship ML up? <efraim>I think the plan is to add it by default to %desktop-services and to export it but I'll go ahead and send it as a patch to the mailing list so we can discuss it more <guix-vits>in another hand it should be as easy as with elogind-service. <PurpleSym>Is it possible to run only certain phases of `guix build` (say, everything up to 'install) and drop into a shell exposing the build environment afterwards? <sneek>Welcome back civodul, you have 2 messages! <sneek>civodul, efraim says: any suggestion where I should add the fontconfig filesystem? I was thinking (gnu system file-systems) next to elogind but I wasn't sure if that was better than (gnu services desktop) <sneek>civodul, g_bor[m] says: What would it take to get an internship ML up? <civodul>efraim: i would add it to %desktop-services as a 'simple-service' extending file-system-service-type <PurpleSym>guix-vits: Hm, interesting, Iâll try that. I was hoping for something like `guix build -K`, which aborts after 'build no matter if it fails or succeeds. <guix-vits>PurpleSym: idk if `(invoke` can work interactively, though. <g_bor[m]>I am working fomr home for a week, som some things are not working as usual <g_bor[m]>We rarely leave the house, but aside from that everything is fine. <g_bor[m]>I was asked to spin up an internship mailing list, but I asuume we are not in direct control there. <civodul>heh, i'm now working from home as well <civodul>an internship mailing list for Outreachy + GSoC? <civodul>wouldn't it be better for future interns to be on the main ML? <civodul>the main drawback is that it might seem intimidating <davidl>Im getting a guix pull error: Migrating profile generations to '/var/guix/profiles/per-user/root'... \n guix pull: error: File exists: "/var/guix/profiles/per-user/root/current-guix" - is it safe to delete or move that symlink and rerun guix pull? <rekado_>guix-vits: thereâs no problem with invoke. There is no feature to run build phases selectively, but one could generate a different derivation by throwing out all build phases that follow a certain build phase. <davidl>guix-vits: not sure what your asking? <davidl>guix-vits: ah yes it is. I found some info on bug-guix about it now as well. <rekado_>guix-vits: this doesnât matter for the question. <rekado_>this would also happen with an older version of Guix on Guix System when upgrading. <guix-vits>rekado_: if this on-top, then davidl already pull as root, so sudo will not help. <rekado_>âŠ? The error comes from migrating profiles. This is unrelated to running Guix on foreign distros. <PurpleSym>guix-vits: Thanks, I was able to figure out the original problem with `guix environment`. <davidl>guix-vits: The installation is very new. I am running guix pull as root, using GUIX_PROFILE=~/.guix-profile ; source $GUIX_PROFILE/etc/profile in .bashrc - does that give any leads to what the issue might be? <guix-vits>even if no, you distro will not suffer, only Guix package manager. <davidl>guix-vits: I can not afford that in this instance :/ this must work <g_bor[m]>civodul: Actually the interns requested that. They are already on the main ML and we encourage them to communicate there, so that others can chime in. <g_bor[m]>I believe that the main purpose would be share intermediate results, and things like that. <raghavgururajan>g_bor[m], civodul: I was thinking the separate ML so that intern project related development mails would not mix/confuse with regular development mails at guix-devel. <g_bor[m]>They sould still come to the main list with questions. <civodul>g_bor[m], raghavgururajan: it's fine to use guix-devel or help-guix (better) for questions, it's not "confusing" IMO :-) <raghavgururajan>> I believe that the main purpose would be share intermediate results, and things like that. <raghavgururajan> g_bor[m] Yeah, so that it easy to track the updates and progression. <raghavgururajan>civodul: I understand, questions are fine. I was referring to status updates and for record of conversations between mentors and interns. It will be also easy for intern organizers to view and track information. <raghavgururajan>g_bor[m], civodul: I would also like to suggest dedicated git branch for intern-projects. Once the project is completed, it can be merged to master. This also helps guix's master to not get interrupted or break by the project's updates. Also git logs will be neat and clear. <PurpleSym>When inheriting a package, is it possible to âmodifyâ certain aspects of (source (origin âŠ))? I want to create a package with an additional patch applied to its source. Everything else stays the same. <civodul>raghavgururajan: re status updates, it's fine to have them on guix-devel, but if you think it can help organizers, we could create a separate ML <civodul>as long as project-related discussions remains on the main ML, that's fine :-) <rekado_>PurpleSym: (package (inherit this) (source (inherit (package-source this)) (patches âŠ))) <brendyyn>How can i make wireshark work on guix sd? it doesnt run as a sudo. <raghavgururajan>brendyyn: If you would want a program to run as system daemon, you need to add it as a system service. <brendyyn>is that how you are supposed to run wireshark? <raghavgururajan>Based on your use case. You can install a program in root profile and run. <raghavgururajan>Based on your use case. You can also install a program in root profile and run. <efraim>what's the output of `which -a sudo` <efraim>the first should be /run/setuid-programs/sudo <brendyyn>i guess i need to create a wireshark group ? <civodul>Jami errors out with: "dring is not available, make sure it is running" <civodul>raghavgururajan: there's no ring-daemon package, is there? <raghavgururajan>civodul: I believe dring (ring-daemon) is responsible for managing DHT. <civodul>raghavgururajan: the 'jami' package only provide 'jami' and 'jami-gnome' <raghavgururajan>civodul: Yeah, I meant it should also provide dring, which is currently missing. jami was previously known as ring. <civodul>so our package currently appears to be unreliable <g_bor[m]>civodul: there is a quite long ongoing packaging effort to get jami in shape. You can find references on the ML. If I got it right we are waiting for upstream to update pjproject. <civodul>i did notice long threads on this topic but i didn't read them <civodul>these days i feel like a good VoIP solution, ideally decentralized, would be welcome <brendyyn>i believe apteryx was playing with jami it some point <civodul>raghavgururajan: we don't have jingle it seems <civodul>we have Dino, but i don't know if Dino supports that <civodul>has anyone looked into Jitsi packaging? <brendyyn>ive wanted to package meet.jit.si but haven't dont anything yet <efraim>tons of javascript for the web frontend, lots of java packages on the backend <efraim>I'm trying to throw together a hacky working container/vm for the biohackathon next week <janneke>dongcarl: is i686-w64-mingw32-g++ from gcc-7 working for you? i'm still (even on core-updates) having weird problems <raghavgururajan>civodul, efraim: There are Signal and Wire. But centralised. Yet free software and has desktop versions. <brendyyn>i set up a server once but it was never as reliable as using the public node. never understood why <brendyyn>is there any barrier to including electron in guix? *raghavgururajan currently uses calls.disroot.org <efraim>looks like calls,disroot.org doesn't like icecat <civodul>efraim: great you're looking into Jitsi! <raghavgururajan>efraim: Yeah, it's because of WebRTC. Works on ungoogled-chromium though. <civodul>but yeah, it's one of these things that's heavily JS-loaded i guess <brendyyn>guix must embrace the future even if it doesn't fit our ideals :P <andydarcyjewell>hi peoples, i'm trying to package a program (called factor) that isn't in guix, but I'm having trouble working out what I need to do. I've read several tutorials, but they all seem too abstract, or focused on things that have already been packaged. Factor is a tarball install with an automated build script, and I can successfully get that up and ru <andydarcyjewell>nning on stock debian *without* guix, but struggling to even do the *with* guix. <alextee[m]>andydarcyjewell: looking at similar packages is probably the easiest way to do it <alextee[m]>you an look at a package's definition with `guix edit` <alextee[m]>then you can build your package with `guix build -L <directory where this .scm file is in>` <andydarcyjewell>alextee[m]: thanks for the hint, but I'm pretty new to guix and scheme (as I said, I've read tutorials, but it's a lot to take in). Is there a guide or blog post that shows what the process is like for making a new package? I don't think looking at existing manifests will help me work out how to get to that point. <brendyyn>,module (guix man-db) => no code for module (gdbm) <alextee[m]>andydarcyjewell: learn the basics of lisp first i guess <alextee[m]>i watched a 1 hour video on youtube (invidious) on basics of lisp/scheme and that was enough to get me started <alextee[m]>it takes some time to get used to the parens and the way calling functions works <alextee[m]>if you don't know even basic LISP, writing packages is probably impossible <andydarcyjewell>alextee[m]: I've read through the scheme crash-course, but it seems to assume a lot of lispish prior knowledge that doesn't mesh with my mainly non-functional programming experience (python,C,perl,Go, etc.) <alextee[m]>andydarcyjewell: i can understand, i'm a C guy too. let me find it, 1 sec <andydarcyjewell>alextee[m]: I'm fine with the lisp syntax (lots of irritating single parentheses!) but it's manly the way the terminology differs <brendyyn>andydarcyjewell:to create a package, download the guix git repo and create a branch to work in. your package will go in gnu/packages/ in one of those files depending on what it is. its not too important which so just pick the category that makes the most sense. then start a fresh package definition at the bottom of the file with (define-public my-package (package .....)) <alextee[m]>starts from the bare basics so no prior knowledge is needed <andydarcyjewell>alextee[m]: I actually read a book on lisp in the early 90's... but didn't have access to a decent lisp system, so it never stuck <brendyyn>then just try fill in the form taking guesses from other packages <alextee[m]>i suggest watching the whole thing when you have time. it has a nice pace that builds up as it goes <brendyyn>then to test it and fail, in your git repo you run `guix environment guix`, then ./configure --localstatedir=/var; make -j; and finally ./pre-inst-env guix build my-package <brendyyn>then you'll be confused as it fails so you paste your definition in paste.debian.net and ask here to have someone explain whats going on <brendyyn>for learning i think its good to try and understand the data types. like package is a record type, you can look that up in the docs or srfi ***jonsger1 is now known as jonsger
<efraim>After packaging all the rust dependencies for librsvg@2.46 I might check into changing it to the cargo-build-system and pull in whatever it's using now, should be better than what we're currently doing ***ng0 is now known as nikita`
<civodul>sneek: later tell sirgazil thanks for the new screenshots, neat! ***jonsger1 is now known as jonsger
<marmulak>any ideas about "guile: warning: failed to install locale" <brendyyn>marmulak: too many ideas. its a common annoyance <brendyyn>it means that GUIX_LOCPATH is set wrong or you've got a missmatch between installed glibc and the guix running <marmulak>I'm still learning how to do anything with this <marmulak>I ran guix pull, then should do guix package -u ? <brendyyn>are you running guix on a foreign distro? <brendyyn>it's not really your fault. this is just a bug that is troublsome so it hasnt been fixed yet <marmulak>Yes I installed it on Fedora just to try it out <marmulak>My $PATH does include my local guix directory <marmulak>So I see GUIX_LOCPATH is being defined in profile.d/guix.sh apparently correctly but I don't know why it's undefined in my shell <brendyyn>it may not work until you log out and log back in again <marmulak>Seems my .guix-profile dir doesn't exist <marmulak>Also is "guix pull" supposed to take a very long time <brendyyn>if you have substitutes enabled it shouldn't be too bad <marmulak>Hmm I do but I enabled them after install <marmulak>I tried installing without substitutes but guix pull eventualy failed to build sed so I enabled them and then it ran to completion <marmulak>I don't know why I'm running it again, just to see if it really finished? lol <brendyyn>its very hard to much hundreds and hundreds of packages all compile correctly on hundreds of different computers ;; <marmulak>OK I think the delay is just my slow Internet. Something is being downloaded <brendyyn>it shouln't hand on that for more than 10 seconds <marmulak>10 seconds sounds right, but how much data do you think it needs to pull in that time? My download speed is like 50 kbps now unfortunately <brendyyn>it should show output though like git does <jonsger>ArneBab: I don't think it does make a lot of sense on Guix due to missing drivers and firmware... <jetomit>also, f@h client is not free (kinda surprised me too) <ArneBab>jonsger: do you mean it doesnât run on the CPU? <jonsger>ArneBab: I guess it does but not as fast as on GPUs... <ArneBab>jonsger: I would not mind that, but not being free is annoying ⊠<guix-vits>"It is important to note that we do release the <guix-vits>scientific modifications back to the open source <guix-vits>community, but do not release information which would <guix-vits>enable donors to cheat on points, which some donors <guix-vits>have done ruining the experience for many others." <anadon>Anyone else have guile 3 fail to build? What is the bugs email again? <ArneBab>guix-vits: thatâs security by obscurity instead of getting the scheme right :-/ â that this does not work on the long run should be obvious if they take even a little glance at game modders. <guix-vits>anadon: freshest `pull` counts, or one need some special guile build environment? <anadon>guix-vits: Just pulled and the build failed from that. <guix-vits>ArneBab: idk, but many people say the same :) *guix-vits triyng pull && build *guix-vits PS: good morning anadon <NieDzejkob>PurpleSym: what does `ssh machine guix --version` output? Checking like this will not run the login shell <anadon>guix-vits: Looks like `guix build` was a null operation. ***modula2 is now known as defaultxr
<PurpleSym>NieDzejkob: Itâs at commit 75c33c888abacc477589fa8aa96c03a8cfbb39e3, which is correct. <PurpleSym>Local version is 771c5e155d7862ed91a5d503eecc00c1db1150ad <marmulak>Man guix is crazy how many gigs of stuff can it install before I have a basic package working <brendyyn>marmulak: that's no different to any other distro. <guix-vits>marmulak: are you sure that the substitutes switched ON (i've 10 Gib limit a month)? <bricewge>Regarding #39332 about adding btrfs-progs based on the file-system-types used. Where such modification take place? <pinoaffe1>Hi everybody, I'm trying to "infect" my hetzner vm, see the guix-config above, but it fails to boot, stating that it is waiting for the root partition to appear <NieDzejkob>PurpleSym: ok, try `ssh machine guile --version` too <bricewge>Would replacing %base-packages with a procedure taking the current operating-system be okay? Like essential-services does. <pinoaffe1>however, when I boot the system with systemrescuecd, the root partition does seem to be labelled correctly - does anyone have an idea what might be going wrong? <PurpleSym>NieDzejkob: 2.2.6 on both ends, but the local version is somehow provided by Ubuntu. <PurpleSym>I guess I can work around that by just using `guix archive`⊠<nckx>pinoaffe1: Which kernel driver does sysrescd use to see your drive? (lspci -v, ls -l /sys/class/block/*/device/driver/module) <jsoo_>bricewge: whatâs the idea? <PotentialUser-90>is there any way to provide the guix installer with a pre-defined config.scm <PotentialUser-90>Im trying to do a completely clean install on digitalocean and getting a bit stumped <nckx>PotentialUser-90: I think g_bor[m] made something like that for their own use. <raghavgururajan>civodul: Could you leave me a message via sneek, after you setup the ML? Thanks! :-) <pinoaffe1>nckx: none of the /device/driver folders contain "module" <nckx>pinoaffe1: And does lspci -v say anything interesting beginning with âKernelâ? <guix-vits>PotentialUser-90: do you need an custom installation iso? <nckx>pinoaffe1: What kind of Hetzner VM is this? <jsoo_>bricewge: Iâm not sure thatâs possible <nckx>Not with %base-packages as a list, hence the procedure question. <pinoaffe1>Kernel driver in use: ata_piix and Kernel modules: pata_acpi, ata_generic <jsoo_>Or desirable. I want to avoid any spooky action at a distance in my system configuration <bricewge>jsoo_: I want to append fs tooling package to the system profile based on the the file-systems in used. I'm looking for a little guidance to where such a modification would be appropriate. <jsoo_>bricewge: hmm. Is btrfs a package? <pinoaffe1>nckx: it's the "CX11" variant, basically their cheapest VPS <nckx>jsoo_: I agree with you, but as long as this doesn't affect people not using [(]%base-packages[)] it's not my problem. *nckx gone full libertarian today. <nckx>Ah, perfect, that's what I was looking for. <jsoo_>I would guess there are a lot of users using %base-packages, maybe trasitively <nckx>Most by far. bricewge: What's insufficient about users adding btrfs-progs (bcachefs-tools, zfs-things, âŠ) themselves? <pinoaffe1>bricewge: I've looked through that thread, don't get the same error message as ellen papsch <bricewge>jsoo_: So, if I don't touch %base-packages and just replace packages' default it might be ok? <nckx>pinoaffe1: But you're not using the installer, right? <jsoo_>For desktop users, I think %base-packages is the base of %desktop-packages <marmulak>wait, so I'm supposed to do guix pull as root? <nckx>Guix looks at the currently loaded modules to warn you if it thinks one is âmissingâ in the new configuration. This works best when installing from Guix itself, other systems might have different sets of modules (vs. built-in or simply different drivers). <jsoo_>Iâm beginning to agree with nckx, bricewge. Why not let the user specify it themselves? *nckx was trying to be *less* of a grumpy curmudgeon. Dammit. <bricewge>nckx: It's just suprising when using Guix for the first time. And also non ext* users get e2fsprogs for free. <nckx>Yeah, that's arbitrary, sure. <jsoo_>bricewge: perhaps %base-packages could be broken into smaller lists to be composed later <PotentialUser-90>and the image needs `cloud-init` installed (presumably so that the DO droplet can control it) <jsoo_>Then it could become interchangeable <nckx>PotentialUser-90: Oh, you don't mean an installer that *deploys* a custom .scm? <pinoaffe1>nckx: no, I used the "bootstrap.sh" script posted in said thread by alex sassmannshausen <marmulak>guix-vits: what happens when I pull as non-root? Something bad? <nckx>PotentialUser-90: You can âjustâ edit âgnu/system/install.scmâ to suit your needs and create a new image. <nckx>marmulak: Pulling as non-root is the standard and recommended way. <PotentialUser-90>when I do a guix pull on that, Im not getting bleeding edge packages right? <nckx>marmulak: But foreign distro Guix, by default, uses root's guix-daemon. If you never pull as root, it never gets updated. If you run âsudo -i guix pullâ once a month and do nothing else with root's guix you'll be fine. <guix-vits>marmulak: idk, but think that on foreign distros it should be done as root. <nckx>Not in daily regular usage. <nckx>You still guix pull && guix install as yourself. <bricewge>jsoo_ nckx: OK I give up, I'll update the bug report. <nckx>Why? IIRC Leo agreed with you, so you're not alone. <jsoo_>bricewge: I think splitting up %base-packages would be a nice change actually. Make a new list of standard packages, but for btrfs <marmulak>so there's just certain things that won't get updated if I don't update as root <nckx>1 thing, the guix-daemon started by /etc/systemd/system/guix-daemon.service. <jsoo_>Or let the user define a function to construct different package lists in their configuration <guix-vits>PotentialUser-90: `guix pull` only acts like `apt update` -- one need to run `upgrade` after. <jsoo_>yes, no code is best bricewge! <PotentialUser-90>@guix-vits thanks, does that then pull bleeding edge? Or is it pinned to 1.01 <nckx>PotentialUser-90: Rolling release (master). <nckx>PotentialUser-90: 1.0.1 isn't a branch, it hasn't changed in a year, so there would be nothing to pull. <nckx>We don't have the volunteers to maintain a stable branch at this time. <jsoo_>bricewge: my problem is that the user has to reconstruct all of base packages if they want btrfs-progs instead of the e2fs ones <bricewge>jsoo_: Splitting it for 2 packages seems too much for just that. <jsoo_>that's why i think making %base-packages by appending smaller lists would be ideal <nckx>(define %btrfs-base-packages (list btrfs-progs)) though. <PotentialUser-90>another question, didnt manage to find an answer in the manual -- I know ELPA is supported as a repo for emacs packages, but there are a bunch of emacs packages I need which I usually build directly from a github repo using straight.el <jsoo_>%base packages has multiple sections with comments right now. each of those sections might be their own list <PotentialUser-90>is there a way of addressing this without relying on straight.el? If there is sample code somewhere of someone doing something similar that would be helpful *nckx wonders if current-guix/âŠ/lib/locale in their paste is even correct, but has become warning-blind regardless. <leoprikler>PotentialUser-90: are those repos perhaps somewhere on melpa? <leoprikler>If they are, then the elpa importer will work for that as well <jsoo_>you could package them yourself and they should Just Work if you use the emacs-build-system, PotentialUser-90. <leoprikler>then you'll have to manually parse the description that straight uses <leoprikler>^ under the assumption that you correctly resolve all dependencies <civodul>apteryx: there's a typo in the manual in the %sudoers-specification commit, where a closing paren is inside a comment <civodul> perhaps at some point we should expose a schemey representation of the sudoers file <PotentialUser-90>@leoprikler yeah dependency resolution was what I was trying to avoid doing myself <jsoo_>Is documentation for the console-font service missing from info? *raghavgururajan will be working on splitting up %desktop-services into %generic-desktop-services and multiple %foobar-desktop-services (for each DE). <PotentialUser-90>a question, but how does one know all of the required `use-module` items? <leoprikler>you either remember where the functions come from or you invoke the interpreter and have it tell you what it's missing <PotentialUser-90>can it be generated automatically after installing the packages on live environment <nckx>jsoo_: Yes. There's a docstring though. <jsoo_>i thought it existed in info some time ago, nckx. <jsoo_>PotentialUser-90: running guix build will often ask you if you forgot an import. It's quite nice like that <nckx>jsoo_: Not in guix.texi, at least. <jsoo_>nckx: hmm, seems like it should be included <jsoo_>is there a reason it is not? <nckx>I'd even say someone should include it. <nckx>jsoo_: It's a very simple service but there's no reason not to document it in the manual. <jsoo_>nckx: i struggled with it for a long time. mostly because setfont's documentation do not mention being able to provide a path to a font <nckx>Yeah. Documenting it in prose would allow explaining where to find the available fonts (I always forget and brute-search my store). <jsoo_>if someone were to add it to guix.texi, would they need to add it anywhere else? <nckx>This hypothetical helpful person would not. <jsoo_>good to know. is there any organization to be aware of in the Base Services chapter? <apteryx>civodul: thanks for letting me know. I'll fix it ASAP <PotentialUser-90>Alternately, see `guix package --search-paths -p "/home/vagrant/.guix-profile"'. <apteryx>civodul: the format is raher complex; it'd be non-trivial <PotentialUser-90>furthermore, can someone tell me why guix doesn't simply just do this for me? (I'm guessing there is a good reaosn that I'm missing) <apteryx>civodul: I have finalized the patch that enables booting from a Btrfs subvolume. I'll send those now. <rekado_>PotentialUser-90: what error do you get? <sneek>Welcome back rekado_, you have 1 message! <sneek>rekado_, guix-vits says: i'll try to accent this more, then. <rekado_>Guix cannot do this automatically because doing so requires changing the environment of the process running Guix (the shell). <rekado_>On Guix System itâs usually enough to start a new shell. <PotentialUser-90>@rekado_ strangely not getting an error now, when I try it, I must made an error before <PotentialUser-90>@rekado_ though in attempting to install nix for example, I now get these errors, even after starting a new shell <PotentialUser-90>error: getting information about '/home/vagrant/.nix-defexpr': No such file or directory <PotentialUser-90>warning: the group 'nixbld' specified in 'build-users-group' does not exist <PotentialUser-90>error: getting information about '/root/.nix-defexpr': No such file or directory <apteryx>civodul: sent as part of issue #37305 (guix-patches) <nckx>jsoo_: Not really. I'd put it before login-service so there's a semblance of lowâhigh level ordering but that's just an opinion. <nckx>PotentialUser-90: Did you create the nix build users & group in Guix's system configuration and reconfigure? <PotentialUser-90>@nckx I did not, and I guess that's where (as admittedly a newbie) I am getting confused - if nix is packaged for guix should it not do that for me if I am working within a live installation? <jsoo_>PotentialUser-90: generally packages do not alter system state (i.e. users and groups) <nckx>They can't, even. Services can. I forgot there was a Nix service in Guix. Are you sure it doesn't create these for you? <nckx>jsoo_: Looks good! I like seeing GNU/Linux, but am not 100% sure it's correct here (Hurd?). We tend to use âthe kernel Linuxâ when talking of Linux feauters/limitations. <nckx>PotentialUser-90: You need to add nix-service-type to your system configuration (roughly similar to adding the nix-daemon service to any other operating system). <nckx>But unlike other systems, packages can't âhelpfullyâ drop in services that start automatically. <jsoo_>nckx: ok so s/GNU\/Linux/the kernel/ ? <nckx>jsoo_: âon(?) the kernel Linuxâ. <nckx>PotentialUser-90: I should warn you that Nix support in Guix might be anywhere between working and completely broken. It's not well-tested or -maintained. <nckx>(AFAIK. Do let us know what happens/explodes.) <PotentialUser-90>@nckx I understand that, I'm actually just trying to import some package definitiosn using guix import nix <store> <pkg> <PotentialUser-90>but it doesnt seem to be as straightforward as the manual is implying, so I thought maybe I was missing the obvious step of having nix installed first <nckx>PotentialUser-90: According to drakonis yesterday, the Nix importer is not in great shape âč <nckx>I don't like to be vaguely negative like that, but they know Nix much better than I do nowadays. <nckx>jsoo_: I didn't validate the mark-up but the text looks good to me. <nckx>Aside: Do you know if there's a user-friendly âlist the available kbd fontsâ command? <jsoo_>ok thanks. i'll submit a patch nckx <guix-vits>anadon: no, it doesn't: "guix build: error: derivation `/gnu/store/x23q5amz0bhzlg8k8j5a6sl0zvzk76d0-guile-next-3.0.1.drv' may not be deterministic: output `/gnu/store/palkxyahaxqqany7caap91iaz5qcv24q-guile-next-3.0.1-debug' differs" <jsoo_>nckx: No i don't. I think to know the available fonts, you have to find a font that provides tty-able fonts or know what is available in the kbd package <nckx>OK, then I'm already doing it ârightâ (sigh). Thanks! <jsoo_>no prob. yeah it's a pain :( <guix-vits>anadon: `guix environment --pure --ad-hoc guile-next -- guile` works. Maybe we both have some setup errors? i'm not being a developer, not understand this things, only can say that build fails for me too. <nckx>guix-vits: The above error isn't fatal, it just means that the build isn't reproducible. The result should run just fine. <nckx>Or if it doesn't, that error is not to blame. <anadon>This machine was set up using the provided instal script. Is this something we should get nckx to guide on? *nckx is just about to leave for dinner, unfort. <nckx>Plenty of other competent helpful folks here. o/ *anadon isn't one of them yet <guix-vits>anadon: like in that joke: how can you give a preference to one based on the wrong answer? -- on the exams, he answered: "i don't know", you're answered: "neither i am". <guix-vits>anadon: do you've guile-next in system's profile or in user's profile? i'm just did `pull` `package -u` and `guix package -m my-profile-manifest.scm` (added guile-next to it), and everything works. <guix-vits>i've no idea if that good or bad to have guile-next in system's profile, though. <guix-vits>thanks for improvements on this part of manual, again. <anadon>Iactually haven't gotten to understand profiles yet. <nckx>There is not a single traffic jam in all of Belgium (đź) so I'm early. Did you get any further with guile-next? <guix-vits>nckx: installing it as is works on my machine, at least for user guix-vits. <nckx>I've also not had problems installing Guile. All my guile{,-*} packages are in my user profile though. <guix-vits>anadon: again, i'm not a developer; my understanding is that there is a system's profile (it's governed by config.scm), and the users profiles (root, ...; these ones are independent of each other). System's profile is critically important, and every new generation creates new entry in boot-loader. Having a minimal system's profile allow one to update early, then wait until there is substitute for an Fat Package is available, to <guix-vits>and each user do `guix pull` independently. But on the Guix System sudoers can use `sudo guix reconfigure /etc/config.scm`, as sudo is comes with `-E` flag by default (which is preserving ENVIRONMENT), so system profile is get updated -- using sudoer's results of `guix pull`. *guix-vits reboot, to update Kernel <nckx>That is correct (I'd replace âsudoerâ with âthe regular userâ for clarity but that's a nitpick). <guix-vits>check out the emacs-w3m -- it has a Bookmarks page that one can edit as HTML, a fonts that always same size, and a white-on-black color theme that mandatory for all sites, but it has no JS support. <guix-vits>and rendering of huge pages is rather slow, comparing to Chromium engine. <Blackbeard>Is the only thing that annoys me and why it isn't my main bcowser <guix-vits>Blackbeard: generally no -- but i'm instead enlarge it for terminal emulator. for kitty it's "Ctrl Shift =". <guix-vits>in qutebrowser i'd set some settings in `:set`, and set the default zoom level to 150%, but yet some pages have too small fonts. <Blackbeard>But I plan to use it more when I am done with my school in August <guix-vits>Blackbeard: There also the epiphany (Gnome Web) browser; i'd found it rather mouse-driven, though. But it is enforcing the user's stylesheet, so the fonts sizes, the color, and the line-height can be governed with CSS. But i'm never managed to write good stylesheet. <g_bor[m]>civodul I have just seen you message about bugs. The links seem to not give the right results for the serious and important bugs. <civodul>g_bor[m]: too bad, the results looked sensible <guix-vits>Blackbeard: in preferences there even was a button to edit the stylesheet. like `* { font-size: 16px !important; }`, but i'd forget. of course that will broke many sites, as * match any element on the page. <efraim>rekado_: guile-irc is missing the '2.2' in %out/lib/guile/ <marmulak>if I ran guix pull as root, that means there's no need to do that as user, right? <marmulak>but somehow it seems root and user somehow have their pulls done separately <civodul>marmulak: exactly: "guix pull" is per-user <rekado_>marmulak: root is just another user account. <rekado_>every user account can have its own version of Guix, independently managed. <marmulak>damn so I have to do this on both accounts <rekado_>if you have only one ânormalâ user account (other than root) then you donât really need to use Guix with root. <rekado_>you could use your regular user accountâs Guix for all purposes <rekado_>gain super user permissions with âsudo -Eâ, but use the same version of Guix as your regular user account. <jackhill>marmulak: are you using guix on another distro or guix system? <marmulak>when I do sudo -E is that mainly just for guix pull or should I also use it for package operations as well <NieDzejkob>all guix commands should be done using `sudo -E` <marmulak>I guess everything if guix-daemon is not owned by root <jackhill>marmulak: most everything you'll want to do as your user (unless you want to install stuff with guix for the root user to use). <jackhill>the additional thing to be aware of for guix on other distro v. guix system is that the service unit for the guix daemon on other distros comes from root's version of guix, so you'd either want to update root's guix periodically or change the unit to point to your version of guix. <marmulak>well I was told unless I run it as root then guix itself won't update <marmulak>jackhill: yeah I was told I can edit the systemd file to point to my user's guix-daemon <jackhill>marmulak: great, I didn't see that and wanted to make sure you didn't miss it :) <marmulak>I'm still confused but I'll learn over time <marmulak>I need to look at manuals and tutorials and whatnot <marmulak>the latest thing to confuse me is that I tried removing a package and now it's re-downloading subtitutes for things I had just installed earlier <marmulak>although I suspect that maybe somehow those files were deleted when I deleted generations and ran the garbage collection, and it just wants the files for everything currently installed to be present, but I can't be sure <bricewge>rekado_: Is it normal that recently closed bugs still shows up when querying mumi with is:open, like the links in your last email to the ML? <jackhill>marmulak: there is definitely a lot to learn. <jackhill>marmulak: the purpose of grafting to allow security updates without requiring rebuilds <jackhill>marmulak: esentially, since packages contain the file paths (a.k.a. store references) to other packages, rather than rebuilding those to refer to a fixed dependency, the references are (binary) patched. As lfam says the documentation as a more complete and accurate description. <marmulak>ok so I edited guix-daemon.service so it points to my user's profile instead of root's <marmulak>so now I just use sudo -E when I want to do something <marmulak>based one what I think -E does, I thought sudo always worked that way <marmulak>I thought you needed a special option if you wanted to get root's login env <jackhill>marmulak: no, I don't think you should need sudo at all now <marmulak>and the daemon will still update itself? <jackhill>yes, when you `guix pull` as you, ~/.config/guix/current (which is where your .service file points to now) will get the new daemon binaries. <jackhill>you'll need to systemctl restart guix-daemon to start using them though, but that's normal non-guixy stuff <rekado_>bricewge: a little delay is normal. Weâre updating the local database every 30 seconds, but the worker to do that had crashed, unfortunately. <marmulak>ok so I'm trying to start over "from scratch" and I removed all my packages, deleted pull and package generations, ran the gc <marmulak>now when I run guix package -i hello, it still wants to download like 30 dependencies <rekado_>looks like we canât connect to debbugs right now⊠<rekado_>I donât have time to investigate this right now; will check on mumi later :-/ <lfam>marmulak: It's like downloading software required to build the profile, such as building the man page database and other things like that <lfam>You already had this stuff but it got deleted with `guix gc` <lfam>They are not dependencies of hello but required for package management in general <marmulak>lfam: I thought the idea of GC was to remove unused things, not used things <lfam>marmulak: What's protected against the garbage collector are "profiles", which are the things you install <lfam>Or rather, profiles are collections of things you've installed <lfam>Anyways, what you saw was normal operation. I usually don't run the garbage collector until I'm out of space <sneek>sirgazil, you have 1 message! <sneek>sirgazil, civodul says: thanks for the new screenshots, neat! <sirgazil>What command options would you suggest to create the VM and to run it? <lfam>sirgazil: `guix system vm-image path/to/config.scm` <lfam>You'll need to install QEMU or get it with `guix environment --ad-hoc qemu` <marmulak>am I right in assuming if I never run gc, nothing ever gets deleted (like, all previous installed versions of everything) <lfam>Thsat's right marmulak. Guix never deletes anything on its own <marmulak>I'm thinking of putting guix pull in a nightly cron job <lfam>In the long run, we will probably need to create some kind of gc automation, at least for desktop use cases <lfam>It's up to you. I still do it manually once in a while because it can lead to extra work when doing things like `guix package` <lfam>And when updating all my packages I usually do --dry-run to see if I will need to build anything expensive <lfam>Hey sirgazil: If you have trouble regarding KVM let us know. You really need KVM to work in QEMU <marmulak>hmm well I think I finally did it, got guix completely set up and snappy <marmulak>now I just need to figure out what to do with it <lfam>One of my things is using Guix to easily manage and deploy a custom FFmpeg for my job (related to media) <lfam>The use case will find you... <marmulak>so it helps you build it with custom options? <lfam>marmulak: With custom dependencies (nonfree or incompatible license) and options <NieDzejkob>For me, the killer feature is `guix environment`, it's like Python's virtualenv but for everything <lfam>There are media codecs without GPL compatible implementations but I have to use them <NieDzejkob>I use it for pretty much all of my development work <lfam>Yeah, guix environment is awesome <marmulak>let me get this straight... you're using GNU to help you use non-free software? wtf? <lfam>Freedom 0, the freedom to use the software as I see fit <lfam>I don't share details on Guix communication channels though <lfam>It's actually free software, just not compatible licensing <lfam>It used to be considered nonfree but the FSF changed their mind <lfam>Or perhaps the license changed, I don't know <marmulak>what does running guix environment even do <lfam>It changes the result of the `env` command basically <lfam>It changes the environment in which it is run, adding or removing software <lfam>So you can make some program available without adding it to your main profile <lfam>It is really powerful, and can even create disposable operating system containers <lfam>It can compose with your existing environment or start fresh <lfam>One of the nice features of Guix for new users is being able to install software without needing root privileges <marmulak>but I'm sort of getting the sense if I want to develop my own software and distribute it, I could package it with guix <lfam>And being able to roll back in case something breaks <lfam>A full development setup included in the Git repo, using Guix <lfam>But, the best way to distribute your program with Guix is to use the programming language's standard distribution tools in the normal way. Then Guix and all other distros will be able to easily package your software <lfam>So, for C, that's autotools. For Python, PyPi. And etc <lfam>It gets complicated when people try to do their own thing <marmulak>I take it most people on here are using the native distro? <nckx>Good fake IRC morning Guix o/ <lfam>What do you mean marmulak? <nckx>marmulak: Probably, although we don't telemeter you. <nckx>I read that as Guix System, lfam. <lfam>Sure seems like a lot of Guix System users, it's really cool <sirgazil>lfam: Running "guix system vm-image my-config.scm" fails, but "guix system vm my-config.scm" works. What qemu options should I pass to the resulting script of the latter command? I really don't anything about qemu :) <marmulak>I think I'm crazy for installing guix on top of Fedora but it actually works surprisingly well <lfam>sirgazil: For the latter, you just run the shell script returned by the `guix system vm` command. But it won't be a full simulation and probably will not be very useful. Why did vm-image fail? <lfam>marmulak: I use Guix on Debian for my primary workstation and it works great. It's a first-class supported use case <sirgazil>lfam: civodul recommended "guix system vm" in the bug report though. <lfam>Go ahead and try it then <marmulak>well guix has the advantage of using mostly its own files and does minimal config to integrate with the base system <efraim>sneek: later tell rekado_ do you have any notes from using guile-irc? <lfam>Maybe the config.scm is malformed <lfam>Anyways, do what civodul said :) <marmulak>earlier about what you were saying, that there's no need to use guix as root, what happens if I were using Guix System, then wouldn't I have to do system-wide updates as root <lfam>You can do them as your own user with `sudo -E` marmulak <lfam>That would use your own user's copy of Guix <lfam>So, you would have root privileges but not actually "be" root <sirgazil>lfam: I'm using my real system config. Maybe "guix system vm-image" expects a config with different file system information? <sirgazil>Anyways... Running "$ /gnu/store/xckghrr0hxpw902vkz0hyc8gpszjh184-run-vm.sh" fails: <marmulak>I think when I tried running guix with sudo -E on my system it wasn't using my user's profile actually but was doing it for root <sirgazil>Could not access KVM kernel module: Permission denied <sirgazil>qemu-system-x86_64: failed to initialize KVM: Permission denied <lfam>sirgazil: You need to add your user to the kvm group <nckx>sirgazil: You need to add the guixbuilders to the kvm group, or yourself, depending on who's trying to run qemu. <nckx>marmulak: That shouldn't happen with -E, but we can't know for sure. <sirgazil>Ok, it's me who's trying to run qemu. I'll reconfigure then. <lfam>`guix package --list-generations` and `guix package --switch-generation` <marmulak>OK so my test is simple, root has no packages installed, on user I install one (hello), so if I do sudo -E guix package --list-installed it should be the same as if I did it without sudo -E but it's not!!! <nckx>ârollbackâ is just sugar on top of that but I guess it can be scary if you don't know that. <nckx>marmulak: No, it's correct. We had a misunderstanding. I read â I think when I tried running guix with sudo -E on my system it wasn't using my user's profile actually but was doing it for rootâ as talking about the âguix pullâ profile (current-guix). <nckx>And âusingâ as âinvokingâ, when you meant it as âmanipulatingâ. <nckx>You're always using at least two profiles: one created by âguix pullâ that only has the latest guix in it, and one managed by that guix that has all your other software in it. <nckx>So âprofileâ can be ambiguous but that's not your fault at all, I should've foreseen that. *nckx needs to update their emojo font. *janneke thought https://ci.guix.info/jobset/wip-hurd said: gnutls cannot be built; and after two hours i find that /gnu/store/mbr1kai09zkvx4bv0wbf6gcwx8izlqfv-gnutls-3.6.12 (and its dependencies) builds fine... <sirgazil>lfam, nckx: Thanks, I'm using the VM now. <janneke>eh, huh? In procedure time-difference!: TIME-ERROR type incompatible-time-types: (#<time type: time-tai nanosecond: 631171000 second: 1584563599> . #<time type: time-monotonic nanosecond: 593936000 second: 1584563599>) <bricewge>I'want to build a package several time but "guix build --rounds=2 hello" doesn't work. <lapinot>hi folks, i'm in the process of installing guix, but apparently my disk is encrypted with luks >2 but the guix install image only has 1.7.5. I didn't manage to do update the package but that's probably because i don't really understand guix yet. Any advice? <sneek>rekado_, you have 1 message! <sneek>rekado_, efraim says: do you have any notes from using guile-irc? <nckx>bricewge: Use --no-grafts. <bricewge>Adding --no-substitutes --no-grafts --check doesn't help <rekado_>efraim: no notes, but I built a bot with it; and then I threw it away because I can do the same with a little less work with socat. <bricewge>It build 1 time only with such arguements <bricewge>I'm on c1ec7149ed9950e8e285941ecfe96d9bcf980eed <nckx>I can reproduce with â~/guix/pre-inst-env guix build --no-grafts --check --rounds=10 --keep-going helloâ only building once. Must admit I never use --rounds= though. <civodul>--rounds has no effect when used in conjunction with --check <nckx>So it can only build brand-new drvs 10 times? <nckx>civodul: (Seriously) why? <bricewge>Without --check it doesn't work too "guix build --no-substitutes --no-grafts --rounds=2 hello" <nckx>bricewge: You've already built hello. <nckx>You need to modify hello in some way so the derivation hash changes, then you can build it twice, once. <nckx>And explains why I've never encountered this since folks generally only test their own changes/updates for reproducibility. I guess. <nckx>Or it's one of those âoh I thought everyone knew it was brokenâ things đ€· I didn't. <nckx>bricewge: You can still build it as often as you like with --check, you just have to provide your own âfor i in {0..9}â loop. <nckx>Or just âwhile ⊠build âŠ; do :; doneâ and go to bed. <bricewge>nckx: GC'ing is enough for rounds to work once after it. <nckx>That would throw out too much to my liking but go for it if it works for you. *nckx has horrible gcroot hygiene. <bricewge>guix gc -D $(guix build hello) clean only the one path I don't need. <nckx>That's because you don't. <anadon>Unlike most IRC channels I've encountered, boy is this one busy. <civodul>nckx: not sure there's a good reason; this is happening in the daemon, taken from Nix <sirgazil>GNOME Clocks has notification problems too (alarms won't notify). Maybe there is a general problem that makes GNOME apps fail to notify. <rekado_>sirgazil: what do you mean by ânotifyâ? <rekado_>I just set up an alarm, hid the Clocks application, and promptly got a little notification with Snooze button. <sirgazil>No, I'm currently using GNOME in a virtual machine created with my system config. <sirgazil>Which is a system configuration created initially with the graphical installer. <sirgazil>An old version of the installer, maybe 1.0 <sirgazil>rekado_: Do you use alarms often? Because with GNOME Calendar notification worked alright the first time I set an event, but then it never worked again (no desktop notification). <janneke>hmm, we have a pretty harmless mingw cross build problem with c++ <rekado_>sirgazil: I donât use them often; maybe once or twice a month. But theyâve always worked for me. <janneke>but i haven't found a generic fix yet <sirgazil>I'll have to compare my system config with other GNOME user's config then to see if I'm missing something for the desktop to work better.