<vagrantc>-rc is pretty common and might be worth adding <vagrantc>although *some* projects apparently just use rcN. <vagrantc>i don't know how i missed them on my previous pass, but apparently there are still 26 more 'allows to' <civodul>roptat: did you have a chance to check what's up with "POXREF doc/guix-cookbook.de.texi"? <vagrantc>well, r-vim was just incomprehensible ... so i decided to skip it entirely. <civodul>roptat: np, it doesn't seem to be a serious issue :-) <Blackbeard>successfully built /gnu/store/x5sw5gzqw0qir831azj4c60fkh4w2v90-emacs-org-roam-1.0.0.drv <Blackbeard> /gnu/store/x5sw5gzqw0qir831azj4c60fkh4w2v90-emacs-org-roam-1.0.0.drv <chipb>Blackbeard: might the build have occurred remotely and it hasn't been pulled into your local store? <chipb>wild guess, though. I have no idea. <Blackbeard>chipb: oh, I am building it locally with ./pre-inst-env but for a different architecture, so maybe that is the reason, it would not be on my local store <xelxebar>rekado: Thanks for appropriately interpreting my tiredness-garbled message about "the server". Hear anything from debbugs.gnu.org yet? <xelxebar>mroh: Thanks for the tip about setting the SUBDIRS var. Will give that a try. <terpri>anyone happen to know the status of sml compilers in guix? i'm packaging hcoop.net infrastructure but my smlnj and mlton packages are truly bletcherous <nckx>terpri: But they exists, that's always something. I don't know the status of SML compilers in Guix because I didn't know there were any. <terpri>(we do have polyml, but it can't build/run most real sml programs nor bootstrap the more popular compilers, though it can *almost* compile mlton) <nckx>That's right, I forgot about Polly. <jsoo>sneek: tell terpri that there was some work on mlton and smlnj. I think there is a thread in guix-devel about it. Let me know what you find! I’d love to have ur/web! <sneek>terpri, jsoo says: that there was some work on mlton and smlnj. I think there is a thread in guix-devel about it. Let me know what you find! I’d love to have ur/web! <nckx>sneek is a simple-minded friend. <nckx>Np. ‘sneek: tell jessica …’ just means you're 13 and not talking to her. <nckx>I don't know why that functionality exist. And sneek is just or (and #guile's) private bot, with its own quirks 🙂 <nckx>Also completely undocumented AFAIK. <sneek>Someone once said sneek is a good bot <jsoo>indistinguishable from magic :) <nckx>raghavgururajan: Tomorrow. What for? <Veera>Need help with gdm and guix system reconfigure <raghavgururajan>nckx Tomorrow sounds good. I need to clarify somethings for setting up custom git repos (local), for outreachy. <Veera>initial start msg says started new session c1 for gdm; then removed session c1; gdm does not starts ***apteryx is now known as Guest46862
***apteryx_ is now known as apteryx
<Veera>raghavgururajan: latest git pull <Veera>raghavgururajan: gnome, mate, xfce, enlightenment <raghavgururajan>Veera Okay. There was some issue with gnome-initial-setup and gdm. Could you try disabling gnome (service gnome[...]) and try again? <Veera>raghavgururajan: Are you also Outreachy application? <usney>How do I default to only install binaries instead of building packages? It appears my guix installation has now switched over to compiling instead. <raghavgururajan>usney There is no option to use 'only substitutes (binaries)'. They is only an option to prefer substiutes, if available. If substitutes are not yet built in build farm (ci.guix.gnu.org), guix will build them locally. <raghavgururajan>usney Btw, by guix installation, do you mean installing guix on foriegn distro or installing guix system? <Veera>raghavgururajan: tried removing gnome-desktop-service-type still gdm does not stops <Veera>git log of master says April 8 as last commit <raghavgururajan>Veera Hmm. Then I think its a bug. For now, you can use SLiM or SDDM. <usney>I just have trouble with it working with other desktops that not are not gnome 3. Like the other desktops do not recognize the the correct environment variables so it shows up in the menu. Right now I figure out how to get it to show up in the terminal on openbox but not the menu yet and not the locale language used either. <usney>I have stopped using lxde because it seems that it may stop being developed in favor of lxqt. <usney>I still use openbox though which is the window manager lxde uses. <usney>At least it won't be developed by the original authors especially pcmanfm. <usney>It is a really good light weight gtk option. <raghavgururajan>usney I recently packages xfe. You can give it a spin. It's minimal and fast. <usney>I am still setting up tint2 and openbox <usney>it is command line based but looks similar to a graphical login. *raghavgururajan uses dwm+dmenu+st+xfe <usney>I really like slax it would be nice to make a free software version. <usney>perhaps even have an easier installation method too. <anadon>How should packaging selenium be handled, and by extension the web driver? There's a firefox one kind of available, but it isn't well documented. <anadon>The other options are Chrome, Edge, and Safari. <usney>I don't use desktop icons now or menu icons. since I don't really use the desktop icons. Also openbox menu doesn't display the icons well in the menu and probably speeds it up by disabling them anyways. :) <raghavgururajan>anadon Guix provides GNU Icecat (Firefox Based) and Ungoogled-Chromium (Chrome Based). <usney>I do use the icons on the tint2 panel though <anadon>raghavgururajan: I knew about icecat, but I don't know how the provided gecko driver might integrate into it. <usney>I am going to do a new installation soon. I usually do this every now and again because I loose track of which apps I really need and have too many to go through them all. <usney>So I just make a list of all the ones I currently use all the time or most of the time. <usney>also I am experimenting with single board computers so another reason to fight out the lightest and most comfortable desktop solution for my needs. <usney>oh for the locales and other variables? <usney>I knew there was some way to track which ones you use most often <raghavgururajan>For locale and other variables, look for "Application Setup" in Guix Manual. <usney>there has to be because debian uses statistics for that to know what apps to package in their default iso installation discs they make. <usney>thank you raghavgururajan but some of it helps but with openbox I have to set the variables differently it doesn't seem to recognize the way guix recommends to set it up. <usney>~/.config/openbox/environment is the location for setting that up. <usney>so far I just have the correct settings for guix apps to be able to bash autocomplete and be able to be run from terminal. <usney>I am going to write up when I figure it all out in the guix-devel mailing list to see if they want to include it. <usney>other wise I will probably put it on a blog somewhere. <usney>but the fonts are not showing up and it isn't showing up in openbox's menu either. Just works to launch them from terminal. <usney>I fixed all those issues in gnome but it appears openbox doesn't use it like gnomes does. <dissoc3>so how are yall writing packages? do you build it outside of a scm file and then map the process to the functions? do you just try to write the build? or are you in a REPL running it function by function? <usney>you can use two factor authentication login screen? "login-duo - login wrapper for Duo Security two-factor authentication" <apteryx>raghavgururajan: I'm good! Sleepy :-) <anadon>What package file should facebook's "watchman" program go under? <anadon>apteryx: It watches a directory tree(s) for change to files and reports them. <apteryx>anadon: storage.scm sounds reasonable to me. <Blackbeard>$ git am ../patches/0001-gnu-Add-emacs-org-roam.patch <Blackbeard>fatal: previous rebase directory .git/rebase-apply still exists but mbox given. <nckx>Blackbeard: git am --abort if you don't care about the previous failed patch. <nckx>anadon: Can't think of a better place; as long as it doesn't end up in the admin.scm dustbin I'm happy. <anadon>What is the thing to download git releases? I'm blanking. <nckx>(method git-fetch) (uri (git-reference (url …) (commit …))) <nckx>(file-name (git-file-name name version)) <apteryx>nckx: no matter what I do my localhost machine can't be used in offload machines, it always gets stuck 'waiting for locks or build slots'. I'm guessing it has to do with the way locking is done. <apteryx>(i.e., something like localhost is already locked into a 'build', so it can't grab the lock when attempting to offload to itself) <nckx>Yay! Lock debugging. And you thought you'd be bored during quarantine. <apteryx>has anyone successfully installed key files into their Guix System init RAM disk? <apteryx>I'm thinking of a LUKS key that'll allow a (normally) LUKS password protected machine to boot without the password as a temporary measure easing remote maintenance. <nckx>apteryx: Key on external medium? *vagrantc-pbp finally got the pinebook-pro usable enough to consider irc! <nckx>A key in a world-readable initrd gives me the willies. <nckx>I'd consider it compromised by definition. <vagrantc-pbp>i need to research the whole "grub passes on the key at runtime" idea that i'm 83% sure modern debian installs do by default <vagrantc-pbp>you unlock the key in grub, and it appends the key to the initrd at runtime ... and if your initrd does the right thing, self-destructs the key once it boots <vagrantc-pbp>does the unpacked guix initrd linger around somewhere accessible once you've booted? <usney>does pureos use a degoogled chromium too like guixsd does? <nckx>vagrantc-pbp: I want to believe you. I really do. Source? <usney>pureos does have chromium in it's repo. <vagrantc-pbp>nckx: i seen it on recent debian installs ... but maybe i misunderstood what was going on <apteryx>yes, the goal here is to disable the LUKS security (boot without any password). The machine is physically safe, and loosing completely access to it following an electricity outage is a bigger deal at the moment. <nckx>vagrantc-pbp: Initrd contents should be destroyed before pivoting to the empty ram-root. <nckx>vagrantc-pbp: It's just that I take an interest in these things and it would be news to me. But I've been out of things for a while. Just sceptical. <vagrantc-pbp>although the decrypted master key is available on the running system if you have root, fwiw ... <nckx>Neither of which are likely to show up in last year's back-up, unlike /gnu 😉 <vagrantc-pbp>indeed, don't put a key in a store, or anything that *might* end up in the store. <nckx>The key's in RAM, it would be foolish not to expose it. <nckx>People would think it didn't exist and encryption was magic. <nckx>Them being people & all. <vagrantc-pbp>despite some read forehead slapping moments, it also keeps life interesting :) <nckx>I'm not familiar with Debian org, or where the up-to-date official stuff would be. *vagrantc-pbp actually looks now <apteryx>It caches the first LUKS password entered (not in GRUB, but in Linux), then retries those for subsequent LUKS prompts. <nckx>I mean, you say GRUB can create initrds on the fly, that would be a huge deal (and a lot of code) for me to just miss. <apteryx>The only known security implications of this script is possibly swaping the key content, so your swap should be encrypted. <vagrantc-pbp>it's just a cpio archive ... there's in-kernel code to do that <vagrantc-pbp>you can make a single-file cpio archive and just append it to an existing initrd and the kernel will extract it into the initramfs <nckx>Are you initrdsplainin' initrds to me 😛 <nckx>But you're not doing it from Linux, you're doing it from GRUB. <vagrantc-pbp>as an initrd myself, i feel like i have privledge to explain initrds <nckx>I think your initrd privilege is the problem here, vagrant. <nckx>vagrantc-pbp: Well no, that's the thing. <nckx>There's no fs writing code in GRUB at all. <apteryx>actually, my LUKS key would need to be saved with the GRUB files, I guess. Otherwise a password is required to unlock the rootfs (which contains the /gnu/store and the initrd) <vagrantc-pbp>you don't need to pass a filesystem, you just need to pass an additional (or appended) initrd <nckx>It looks remarkably shell-like and some might consider it bloated but it's still easy to be misled. It's mainly smoke and some mirrors. <nckx>vagrantc-pbp: GRUB implements cpio reading as a file system driver 's why I mentioned them. <vagrantc-pbp>there is cpiop code in grub ... weather it's creation is another question <nckx>Just grepping the GRUB for cpio is misleading. <vagrantc-pbp>well, if it didn't return any cpio code, the question would have been solved ... since it's there, there's ambiguity :) <nckx>We're so used to booting ‘minimal’ Linux systems and having a RAM file system that it's very very hard to unlearn that when looking at GRUB. There is no root file system. <nckx>Since we're only talking about one (key) file we could cheat. { echo $cpio_header; cat key file; echo $footer; } > chunk of RAM, tell the kernel there's a second initrd there. <nckx>I'm not sure that's 100% secure but one could ask the people in charge. <nckx>It's just such a bleeding obvious approach that I fear the answer must be no. <vagrantc-pbp>it's also possible i was speculating incorrectly and it was just embedded some keyfile <vagrantc-pbp>alternately, you could read the keyfile directly off the filesystem, since you've already decrypted it <apteryx>vagrantc-pbp: yeah, I realized that it won't work to put it in the initrd, since the initrd lies on the encrypted LUKS iteslf. <nckx>That's the standard way to do it. <vagrantc-pbp>but yes, something along the lines of your cpio header trick would work <vagrantc-pbp>apteryx: for passwordless, yes ... for a single password entry, that will work <nckx>That's what Debian actually does, I think? <vagrantc-pbp>but for passwordless, you could have the key on a usb stick or something, maybe grub can read from that, and the initrd could read from that, etc. <apteryx>vagrantc-pbp: yeah, I'm trying to achieve a password-less reboot. <nckx>GRUB's cryptomount doesn't support reading a key file. <apteryx>I`don't know much about LUKS keys... Does the LUKS metadata stores the "location" of a key? Do you need to pass the information of the key location when attempting to unlock the LUKS partition? <vagrantc-pbp>i think it's different weather luks v1 vs. luks v2 ... and grub only supports luks v1 last i heard <nckx>apteryx: No. The key is just stored in the LUKS header. It's encrypted with [a key derived from] your passphrase. <vagrantc-pbp>think it's even possible to have the luks headers on a separate media? <apteryx>vagrantc-pbp: it's a PC at work secured in the office. I put LUKS on it mostly to not worry too much about drives eventually being decomissionned with data on them. <apteryx>nckx: ah, sorry, I meant key *file*. <vagrantc-pbp>apteryx: but wouldn't the drive still have the data sufficient to decrypt it ... or do you somehow separate that? <apteryx>I know LUKS keys are in the header and password encrypted. <nckx>Sorry. Just making sure. <nckx>The LUKS headers don't have a ‘hint: look on drive with UUID foo’ in them, no. <vagrantc-pbp>for passwordless, unless you have multiple drives for the data, it would at best be security through obscurity <apteryx>vagrantc-pbp: I'll make sure the data to decrypt it (the key file) is gone when I stop remoting and can revert this. <nckx>I don't think separate LUKS headers + GRUB is at all possible. Choose one. But I'm no longer speaking from experience on that point. <vagrantc-pbp>there are cute things like making a "passphrase" out of "unique" booted system information <apteryx>nckx: ah, so a LUKS key file can be described as a 'separate LUKS header'É <nckx>Eh, no, that was me thinking too much out loud. But the answer for both is the same. <nckx>GRUB is *really simple*. It just pretends otherwise. <nckx>If need key, prompt user, else die. That's the extent of the cryptomount module. <vagrantc-pbp>no second chance if you get it wrong, either, which is... challenging <nckx>If I sound annoyed I'm sorry, it's because like you I once thought I could build cool things like that 😛 But the answer is always: boot a Linux kernel, script your cool stuff, kexec your coolness. Alway. <apteryx>how to you script decrypting a LUKS partition using a key file in GRUB? Do we have the usual cryptsetup tool there? <apteryx>(I guess not, but something similar perhaps?) <brendyyn>can screenshots from the guix homepage be used on wikipedia? <nckx>apteryx: You can't and no. <Blackbeard>I have a problem with an emacs mode I am trying to package, it says "Opening input file: No such file or directory, /home/blackbeard/.guix-profile/share/emacs/site-lisp/dict/english.txt" <Blackbeard>that is correct the file is in "/gnu/store/jgh8n39aia9riai0xi29d7dzzazgs3y9-emacs-typit-0.2.1-checkout/dict/english.txt" is there a way to put the file in the directory .guix-profile/share/emacs/site-lisp/ <guix-vits>Blackbeard: (plain-file obj in package definition (sorry, no better thoughts)? <nckx>brendyyn: I take that back, I seem to have misinterpreted the ‘GPL’ wikimedia category (our Web site is under the AGPL, so the images are too, so free but not clear yet if that's OK for Wikipedia). <guix-vits>Blackbeard: i'm id10t. dictionary in (plain-file, lol. <nckx>Blackbeard: To me that means that emacs-typit should install english.txt to its <out>/share/emacs/site-lisp/dict/english.txt? <brendyyn>nckx: ok i just wanted a good screenshot of a fully free distro with some different apps running <nckx>Blackbeard: If emacs-typit does that and is installed to ~/.guix-profile, the file will automatically appear at /home/blackbeard/.guix-profile/share/emacs/site-lisp/dict/english.txt. <apteryx>nckx: eh, didn't know it wasn't possible from GRUB. I'll stop searching then. Thanks for accelerating my research toward this conclusion ^^. <nckx>See, that's why I got a bit cranky. It always ends like this. An exciting journey towards disappointment. 😛 Oh well. <nckx>GRUB is like a cool lego kit but then you take the pieces apart and it turns out some are cardboard and the back is missing on others but hey it wasn't visible and some are just 2 different colours fused together and — <apteryx>well now the journey is heading toward my bed, so that's not that disappointing. Good night/day! <nckx>First them = Wikipedia. Tired. Bed. Bye o/ <guix-vits>Blackbeard: typo: ``@code{emacs-tpyit}'' "typit" <guix-vits>Blackbeard: are you packaging emacs-mmt too ("module is missing err")? <Blackbeard>I alread sent emacs-org-roam (which is pretty cool btw) <Blackbeard>emacs-4clojure, emacs-typing, emacs-mmt, and emacs-typit <Blackbeard>whenever I open a Guix source code.scm file in Emacs I get a message that says <Blackbeard>The local variables list in PATH_TO_GUIX contains values that may not be safe <Blackbeard>I always hit no, but it is getting annoying, what should I do? <guix-vits>#metoo, but i've hit y (idk what is that is) <Blackbeard>I think I should hit "!" then to mark them permanently as safe <Blackbeard>I was afraid it would change something in the code so I just hit no <usney>How do I remove old versions of guix installed apps? <rekado_>you remove packages from your profile with “guix remove”, you delete old profiles with “guix package -d”, you throw deleted profiles in the garbage with “guix gc”. <usney>I'll just have to watch those guix videos fully <usney>which videos should I watch for that? <usney>I think probably everyday use the two videos and the one about help new version <usney>I am going to watch them again <guix-vits>Blackbeard: can you share the definition for emacs-mmt? <marmulak[m]>one thing that confused me the other day is that my system definition seems to include %desktop-services which if I understood correctly installs gdm on the system, but I saw in the documentation settings for the use of other dm's but not clear where to put them or if they conflict with %desktop-services and how that'd get resolved <marmulak[m]>also why desktop environments are referred to as -type, in the same document I saw examples with "xfce-desktop-service" but the documentation saying that it's called "xfce-desktop-service-type" <guix-vits>marmulak[m]: you can see them in guix-git tree, gnu/services/desktop.scm: (xfce-desktop-configuration, xfce-desktop-configuration?, xfce-desktop-service, xfce-desktop-service-type). idk <guix-vits>xfce-desktop-service is "deprecated", btw. seems that service-type is a new "form". <rekado_>it should be (service xfce-desktop-service-type) <rekado_>or (xfce-desktop-service), which is the deprecated form <rekado_>these are not instances of services but service types <rekado_>the “service” procedure takes a type <marmulak[m]>to show that it's meant to be used in combination with %desktop-services? <rekado_>using types opens up the way to service extensions <rekado_>they don’t have to be used with %desktop-services <rekado_>%desktop-services is merely a list of useful services <marmulak[m]>where would gnu/services/desktop.scm be located on an installed system? <marmulak[m]>this manpage for "guix system" looks to have some formatting issue <guix-vits>marmulak[m]: about gnu/services: /run/current-system/profile/share/guile/site/2.2/gnu/services , or so ("current-system", not an random guix-version from store). <jeko>Hi Guixters ! i am trying to use `guix deploy` to a digital ocean droplet ! actually, guix returns a non explicit error to me (using command line) how can I get et more verbose ? <jeko>$ guix deploy deployer.scm <jeko>The following 1 machine will be deployed: <jeko>guix deploy: déploiement vers deployed0... <jeko>guix deploy: error: impossible de déployer deployed0 : Wrong type argument in position ~A: ~S <jeko>the last line seems incomplete... <janneke>sneek: later tell jeko, does instrumenting the (guix-infect) script in gnu/machine/digital-ocean.scm help? <guix-vits>Blackbeard: don't forget to use `guix lint` ("no article allowed at the beginning of the synopsis"; "sentences in description should be followed by two spaces") <guix-vits>and emacs-mmt: "no period allowed at the end of the synopsis" <Blackbeard>guix-vits: thanks!! No I've not. Is just I packaged a bunch of stuff in a file and then I am verifying everything <Blackbeard>I am building one by one, indenting, verifying in different architectures <Blackbeard>So when I sent you those they were before checking them. Right now I am working on emacs-4clojure <guix-vits>Blackbeard: though i'm not sure about that. Maybe the package should be patched to search somewhere in /site-lisp/typit/dict. idk how it should be maded.. <Blackbeard>guix-vits: I want to package a lot of stuff now hahha *raghavgururajan is packaging blueman <bricewge>raghavgururajan : Oh nice! I had a go at it, but it didn't went far. <mroh>is there a way to make a simple text entry (eg to insert a chainloader) into (gnu bootloader bootloader-configuration-menu-entries)? maybe overwrite/customize the (builder) in (gnu bootloader grub grub-configuration-file) somehow? <eric-guix>The new release of guix well be libreboot compatible> <xelxebar>eric-guix: Do you mean by supporting different coreboot payloads? Currently, with libreboot+grub, guix should Just Work, no? <jonsger>civodul: amazing. I think we should add some more and more verbose examples to the manual. That is pretty cool :) <civodul>i'd also like to include references to the Guile manual <civodul>like you could click on 'append', etc. <civodul>then that might call for fancier stuff, because there could be lots of mismatches <smithras>What address do I need to send an email to to get it added to that bug's thread? <xavierm02>I'm having trouble macroexpanding modify-phases: (tree-il->scheme (macroexpand '(modify-phases %standard-phases (delete 'configure)))) <xavierm02>I'm trying to get the names of all phases, and the syntax of the functions implementing each phase <xavierm02>The expression above evaluates to the one inside the macroexpand, i.e. the macroexpand does nothing <cbaines>those hyperlinks in the manual are amazing! <reepca>sanity check: if a tcp connection goes for more than 30 minutes without any traffic whatsoever, an error should be delivered to the program trying to read from the socket, right? <reepca>it shouldn't be possible for netstat to report an ESTABLISHED state for 30 minutes while wireshark has shown nothing for the same time, right? <reepca>guix-vits: well I'll be... net.ipv4.tcp_keepalive_time = 7200. That seems a rather silly length of time, but eh. <jeko>Hi Guixters! How re you ? I m looking for help with guix deploy with which I can't figure out why it is telling me "guix deploy: error: impossible de déployer deployed0 : Wrong type argument in position ~A: ~S" <sneek>jeko, janneke says: does instrumenting the (guix-infect) script in gnu/machine/digital-ocean.scm help? <jeko>janneke: i just see your message, but I never instrumented anything yet haha do you mean I have to do things like (pk ...) things related to (guix-infect) ? <jonsger>smithras: send to 38735@debbugs.gnu.org <janneke>jeko: ah, well i supposed that it's the infect script that's failing <janneke>jeko: can you see on the server if the script was executed? ***andre_ is now known as AndreOc
<janneke>either xz-utils being installed, or if guix-binary-1.0.1.x86_64-linux.tar.xz was downloaded? <jeko>janneke: ok, I go check it out <AndreOc>I've downloaded and installed Guix on top of Trisquel <AndreOc>After "bash install.sh" I got the question whether I wanted to "permit downloading pre-built package binaries from the project's build farms" where I typed yes. <AndreOc>Now the question is: how do I permit downloading pre-built package binaries from the project's build farms, as I have had to abort right after the installation? Guix doesn't allow me to reinstall (so I can't reinstall and choose "yes" there). <jeko>janneke: the droplet on Digital Ocean does not exist. I may have missunderstood. Do I have to create it by myself ? <jeko>Ok, so I think there is a problem with the file I give as input to guix-deploy... <drainful>On the topic of guix deploy: how possible would it be to create a deploy environment for digitalocean that resolves to a managed host environment for subsequent deployments so as to modify the existing vps? <jeko>drainful: i'm interested for some point of view as well haha <drainful>I'm currently using nixops to deploy a personal server and I would love to switch to deploy. One solution is simply to use the digital ocean environment for the first deployment and to make a managed host environment manually for subsequent ones. From a brief glance over the source code it seems like it would be possible to create a host environment type to do it for you as long as you could somehow save the ssh key <jeko>well I could try to take some time looking to it as soon as I am able to deploy haha <drainful>jeko: I took a look and I think the error is raised from /gnu/machine/ssh.scm at line 394 <jeko>drainful: thank you very much for this. may I ask you how you find it out (at least if you use the repl? or hack in the repo then using pre-inst-env guix to try changes? or whatever you did), I clearly lack of debugging skills haha so any tips are time saviors <drainful>Just searched for the words "deploy-error", found &deploy-error, and then searched for where that error was raised, and there was only one place <jeko>drainful: cool thank you!!! I m gonna follow the lead then <drainful>jeko: with-roll-back seems to collect errors that arise with the store monad and dump them at you unceremoniously as you've seen; so I still don't know what went wrong <drainful>If it means anything I tried running using deployer0.scm and got the same error <jeko>drainful: It was nice of you to help, I will see how far I can go and I may end up trying to seek for help on the mailing list haha. <jeko>(I could try with ssh keys pasted in the deployer0.scm) <drainful>No problem. Actually I have one idea. By the time the code that raises that error is evaluated, the droplet should have already been created. It's possible that the droplet not existing is causing that error and that either it failed to be created silently, or was somehow destroyed in the middle of deployment. <roptat>AndreOc, that would be ~/.config/guix/current <roptat>(if you have already run guix pull once) <jeko>drainful: ok I keep that in mind ! <red__>hi there! I am a noobie looking for help. I am trying to run Jami on guix and keep getting the following message: <red__>Gtk-WARNING **: 16:47:33.876: Locale not supported by C library. <red__> Using the fallback 'C' locale. <red__>** Message: 16:47:33.877: Jami GNOME client version: b784e232f8412135d76bd643baec14ef9ff0940a <red__>** Message: 16:47:33.877: git ref: unknown <red__>(jami-gnome:4098): Clutter-WARNING **: 16:47:33.882: Locale not supported by C library. <red__>Using the fallback 'C' locale. <red__>terminate called after throwing an instance of 'std::runtime_error' <red__> what(): locale::facet::_S_create_c_locale name not valid <red__>can somebody help with that? <roptat>is this guix on a foreign distro or the Guix System? what does "echo $GUIX_LOCPATH" give you? <red__>"echo $GUIX_LOCPATH" says "echo $GUIX_LOCPATH" <red__>and language would be en_CA.utf8 <roptat>can you check what version you have in /run/current-system/locale? <roptat>have you run guix pull in the last few months? <roptat>and jami was installed after you pulled? <roptat>my guess is that your jami uses glibc 2.29, so it doesn't find the correct locales <roptat>Since you still have 2.28, you must not have reconfigured in a long time, maybe try that? <red__>i can try and do that, although i have had the same problem also when i had the 2.29 <roptat>try this: guix environment --ad-hoc file -- file $(readlink -f `which jami`) <red__>im going to install the 2.29 again to see if that solves it though <roptat>this should tell you which libc it is compiled to <roptat>whatever version that gives you, it's the version you need in /run/current-system/locale <roptat>also make sure you have /run/current-system/locale/<version>/en_CA.utf-8 <red__>ok i just installed the 2.29 Im gonna reboot the system to see if it does any difference ***pie_ is now known as pie_[bnc]
<red__>hi again, the jami is still not working <red__>i keep getting this message guile: warning: failed to install locale. <jsoo>civodul: cool blog post. I wonder if some parts of /var could benefit from a wipe (by configuration perhaps?). We have problems with gdm state sometimes that may benefit from a general solution <civodul>jsoo: yes, /var/lib/gdm or parts of it could be volatile <jsoo>only 6 commits in eee98f9..7133049 and they only touched the descriptions of some packages. <cbaines>The latest revisions look to have been processed successfully on data.guix.gnu.org <cbaines>Well, ignoring MIPS, the armhf-linux compute guix derivation failed, because http-parser failed to build <pkill9>can someone upload a qemu image of guix running on the hurd plz? <pkill9>aaactually i should just make one on a VPS <civodul>mbakke: hmm, wouldn't we just get "evaluation failed"? <mbakke>... right, something should have timed out / failed eventually <simonsouth>So my ROCK64 is up and booting with Guix now. However trying to run "guix pull" fails with <simonsouth>guix pull: error: Git error: the SSL certificate is invalid <simonsouth>This happens even after I've added the le-certs and nss-certs packages to the system configuration. <simonsouth>Is there another package I need to make sure is available? <cbaines>simonsouth, you might need to specify openssl as well, to correctly setup the search paths <cbaines>simonsouth, are SSL_CERT_DIR or SSL_CERT_FILE set? <simonsouth>GIT_SSL_CAINFO=/etc/ssl/certs/ca-certificates.crt <simonsouth>SSL_CERT_FILE=/etc/ssl/certs/ca-certificates.crt <simonsouth>cbaines: But I don't have openssl explicitly included in the system configuration. So I can try that. <cbaines>simonsouth, what exists at those locations? <simonsouth>cbaines: Seemingly reasonable stuff. /etc/ssl/certs has a whole bunch of .pem files named after CAs. <reepca>simonsouth: wild guess, but may as well check to make sure your system time is properly set. It's caused issues with my certificates in the past since my motherboard's persistent clock would get reset when the power blinked. <simonsouth>reepca: Oh, that's a good point---the time is definitely way off. Let's see... <reepca>of course, since then I believe we've changed our ntpd configuration so it should automatically handle one-time large time steps, so I haven't had the problem recently <vagrantc>especially if this is the rock64 ... the single-board-computers are notorious for having RTC issues <reepca>ntpd often doesn't get automatically started for me, though, so I have to 'sudo herd start ntpd'. <vagrantc>in my experience, ntpd doesn't actually bump the clock if the starting clock is way old, say 1970-01-01 or so <reepca>huh, well it worked for setting mine from 2014 to 2020 ¯\_(ツ)_/¯ <simonsouth>reepca, vagrantc: I think that was it. After updating the lock (it was set to 1 Jan 2016) "guix pull" no longer fails right away. <simonsouth>Anyway, thanks a bunch. Pretty sure that was the issue. <vagrantc>i've wondered about a simple service that at least sets the clock to the last built system generation <vagrantc>but haven't tried my hand writing services <nckx>vagrantc: You need to set allow-large-adjustments? #t for that. <vagrantc>nckx: even with that set, with very old dates, it didn' <bdju>You can fix the time with the date command and then synce with ntpd from there <bdju>there's also a fake hw clock thing for SBCs <bdju>I just ran into date issues breaking package updates/installs on a raspberry pi 2 like a week ago <vagrantc>eventually, i figured out how to enable the RTC in the kernel for some rockchip platforms, at least <vagrantc>ntpd only works if the networking is working, as well ... so having some additional failsafes is nice <vagrantc>nckx: i've been seeing a lot of bugs on debootstrap lately ... so hesitated to update it ... hopefully they got resolved in the latest version <nckx>vagrantc: I didn't encounter any but don't hesitate to revert if it breaks something. I suspect you use it more than me. <nckx>It build my Raspberry Pi image at least 🤷 <vagrantc>nckx: haven't been using it, but am subscribed to the bug tracker for debootstrap and see all the bugs <nckx>vagrantc: Their release process doesn't seem to be optimal, no. <mbakke>berlin has a substitute for libusb@0.1, but building it locally fails because of -Werror=format-truncation, what gives? <apteryx>reepca: the default ntpd conf in Guix System allows large adjustment to be made. <nckx>apteryx: But not gigantic ones, according to vagrantc. <nckx>vagrantc: Have you tried openntpd, by the way? <nckx>It's probably more appropriate (=simpler, smaller, good enough) for boards anyway. I don't know if it's more tolerant of the 70s. <vagrantc>nckx: yeah, i started using openntpd on my guix systems <apteryx>vagrantc: perhaps your hardware clock fails to be set by ntp? It will try a large adjustment *once*, otherwise it will throw an error (man ntpd). <vagrantc>i tried using the https reference for openntpd, but that seemed to guarantee that the clock never synced <apteryx>vagrantc: last I tried openntpd it was working for me, with HTTPS. <nckx>I've also added chrony which is even better at keeping machines like that (intermittent connectivity, low-quality system clocks, …) in sync but there's no service yet. <nckx>(IMO it's better for all machines and more accurate than either *ntpd, but that's not relevant.) <apteryx>reepca: I started doing that :-) It's one of my 10s of uncompleted branches though... <reepca>apteryx: great to know! I tried doing that a long time ago but ran into an issue with the emacs .so-loading where it just sort of... did nothing. But I can confirm that issue randomly went away in the past few months. <nckx>apteryx: That's awesome! <apteryx>I hope it'll make it into upstream some day. <nckx>Researching this some more yesterday made me sad, because consensus is definitely drifting towards ‘GRUB is old, use systemd-boot and/or EFISTUB now’. <nckx>apteryx: AUR isn't Arch, I'm not an Archer but AFAIK it's free for all to upload reasonable things. <apteryx>ah, you're right. I missed that detail. <nckx>That doesn't stop us of course, but it's not… ideal. Adding non-trivial Guix System features that depend on patches that may or may not be upstreamed just makes me nervous. <apteryx>nckx: it wouldn't be the default grub package for sure. <nckx>Also because ‘Patches compatible with upstream HEAD (28b0d190) at time of writing, 2018/03/14’. <nckx>apteryx: No, but it would need companion code in the Guix initrd to be useful, I think. <nckx>The use of a GRUB that magics open your LUKS only for the initrd to prompt from a passphrase is limited. <apteryx>It could be a part in rendering a system's boot passwordless when a external USB key is plugged, say, and fall-back to passphrase prompts when the key is not plugged. <apteryx>I reckon not many people would use it, but it seems useful :-) <nckx>I'll probably end up finally adding external /boot support since I now have 3 separate needs for it (undoublepluspassphrase, bcachefs root, and… something else I forgot). <Blackbeard>Is it ok if I send all the emacs patches from the same branch? I had doubts <Blackbeard>If I create a branch for each one and they get accepted. Then all will create conflicts <Blackbeard>But if I use a single branch and one gets rejected that would be bad too <nckx>This isn't GitHub, that's fine, mail don't care which branch your patch came from. It's up to you whether to send them all with ‘git send-email --to=<nnn>@debbugs.gnu.org -<number of patches>’ or open on bug for each. <nckx>Are they interdependent? <Blackbeard>I didn't know so I played safe and just sent two <nckx>Conflicts are only really a problem for you, so it's up to you how you deal with them. I almost never use topic branches for simple packaging. I add them on (my) master and rebase. <nckx>it gives you complete freedom in how you choose to shoot yourself in the foot today. <Blackbeard>In the manual it said opening a bug was preferred <nckx>Blackbeard: ’git send-email -1 --to=bug-guix@gnu.org’ will open a new bug. <nckx>Just don't use -<n larger than 1> unless you mean to open n bugs. <nckx>Blackbeard: Both bugs you opened look fine, so keep doing whatever you're comfortable with. <pkill9>does VLC_PLUGIN_PATH not work for anyone else? *jonsger resumes work on Thunderbird <nckx>Vague movement in the ‘will Thunderbird die upstream before it makes it into Guix?’ betting pool resumes. <pkill9>i just got this message after running `npm install` lol: found 6 vulnerabilities (2 low, 3 high, 1 critical) <vagrantc>nckx: there are a number of arm platforms where a split /boot partition would be preferable, too <jonsger>nckx: :P copyright years a starting at 2017 :P <nckx>vagrantc: My layman's view of booting on non-UEFI ARM is ‘fucked’. Use our blessed partition layout or else. <nckx>But all side-effects are good. <reepca>hmm, "configure: error: found development files for Guile 3.0, but /gnu/store/i8xf43aqrfcrrc4ziskjrlmkqvmkwhbm-profile/bin/guile has effective version 2.2". Is it necessary to run 'guix environment guix' with --pure now? <nckx>That was always a good idea anyway. <nckx>Haven't encountered that error so can't say . <vagrantc>nckx: it's not *that* bad, it's just inconsistant :P <nckx>I've had at least one board on loan that booted partitions by offset, so if you moved any it would break. (Calling them partitions at that point is just a desperate lie 😛). I'm not an SBC person though so happy to hear it's not all that bad. <mbakke>huh, the 'raid-root-os' system test derivation appears to do a full bootstrap on core-updates, I wonder what is causing that <apteryx>mbakke: just that one, or any of the system installation tests? <mbakke>apteryx: not sure, just noticed it on the CI and am trying to build the derivations locally to check *mbakke needs a faster computer <mbakke>I've run other system tests (avahi, openvswitch), so I'm certain not all of them are acting up <apteryx>the install tests are different, they need to build a current guix package, then build a guix installation image (in a VM), then run the installation (in a VM again). <lfam>There should be a server we can log into for testing stuff like that <pkill9>does guix have a golang importer? <mbakke>well there is bayfront, I just haven't bothered creating an account yet <lfam>pkill9: There was a WIP importer in the past, not sure if it would still work now <mbakke>apteryx: cheers, I needed something to procrastinate with ;-) <mbakke>the github user @bindir must be getting a lot of confusing mentions.. <apteryx>mbakke: I'm not sure it'd help much, but on my aging systems I had made a cheat to accelerate at least deriving the 'current-guix' package: https://issues.guix.gnu.org/issue/37305#16, the patch is the one identified with: '[PATCH 1/5] gnu: tests: Reduce the time required to run the system' <mbakke>so far it looks like 'make check-system TESTS=raid-root-os' is doing all the right things <mbakke>perhaps it has to do with how Cuirass computes those derivations, hm <cbaines>I've noticed Cuirass uses slightly different system test derivations, as they don't match up with what's in the Guix Data Service <apteryx>using the 1.1.0 branch, my avahi-daemon doesn't seem to start <apteryx>seems to be a dbus problem, according to messages: Apr 13 15:58:44 localhost avahi-daemon[1439]: Failed to acquire D-Bus name 'org.freedesktop.Avahi' <mbakke>apteryx: was the dbus-system service started at that time? <apteryx>mbakke: yes, I have the dbus-system running. Attempting to restart avahi-daemon doesn't help. <civodul>smithras: hey! so the installer stops at the step where it's looking for Internet connection, right? <lfam>I noticed that, with the online HTML manual, the "one-page" version is updated to include recent changes, but the "one page per node" version is not getting updated <civodul>however, the timestamp sent by the server confuses caching <civodul>perhaps you need to explicitly reload or do ctrl-f5 <mbakke>oh, the system test did eventually try a full bootstrap, inside the virtual machine <mbakke>on core-updates, the installation tests tries and fails a full source bootstrap upon 'guix system init' <civodul>mbakke: not good, is this on core-updates? <civodul>all the tests include the OS-to-be-installed as a dependency of the installation image such that nothing has to be built during installation <civodul>so the game here is to figure out which thing is missing <civodul>typically, look in the list shown by "guix system init" for the package that's "highest" in the graph <mbakke>civodul: installed-os has the same problem <mbakke>there is a '@ build-log 5385 1' just after /init as well <mbakke>which stops just before 'Welcome, this is GNU's early boot Guile.' <mbakke>is there a guix-daemon in the initrd? <mbakke>the uname at the end of the build log above is telling: <mbakke>;;; (uname #("Linux" "gnu" "5.4.31-gnu" "#1 SMP 1" "i686")) <civodul>that bit is not very informative :-) <civodul>perhaps it's provenance.drv that's pulling a guile-3.0.2 variant that's missing from the install image <mbakke>I thought it was a x86_64 test, but probably not on second thought :P <civodul>the one in the log above comes from: guix build -e '(@@ (gnu packages commencement) guile-final)' --no-grafts -d -s i686-linux <civodul>/gnu/store/8yz40w8nlh98p5x9r28n4bgrfqpgrqp3-guile-3.0.2.drv <civodul>so as a quick workaround, try adding guile-final to the GC roots of installation-os in (gnu tests install) <mbakke>the installed-os test seems to be running fine so far, I just got suspicious when it showed a build log during boot, must have been from some other derivation <nckx>Blackbeard: set (default-user "username") <nckx>GDM needs to know as whom to log in. But that syntax error… oh boy. <nckx>Oh, got it, it's a classic. ***rekado_ is now known as rekado
<nckx>You're missing a ) after keyboard-layout in your services field. There's one too many after %desktop-services, so you're passing a nested list. <nckx>If you use emacs and C-M-q the services field you'll see what I mean. (remove …) should be at the same indentation level as (list …). <Blackbeard>ahh that fixed it. I should learn to count better <nckx>You'd have the same problem if you replaced gdm- with slim-, since the error was elsewhere.. <nckx>Blackbeard: Nobody who writes any non-trivial amount of Lisp/Scheme counts brackets. Let your editor do that. 😉 <nckx>It doesn't have to be Emacs but please let it work for you, not the other way 'round. <lfam>The Vim paredit plugin is basically good enough *nckx not sure if that's faint praise or not… <lfam>It sometimes breaks... there's a parameter "paredit_matchlines" that controls how many lines it reads to balance parens. So for long functions it doesn't work unless you change that number <lfam>It's better than counting parens <lfam>It sometimes breaks when quoted text includes parentheses or other "tricky" stuff <reepca>lfam: to be fair, emacs also breaks when the first character of a new line is a parenthesis, even if it's quoted <lfam>Wow, I figured it would be solid <bandali>also, iirc there was some recent discussion about that on emacs-devel <nckx>‘The convention speeds up many Emacs operations, which would otherwise have to scan back to the beginning of the buffer to analyze the syntax of the code.’ <bandali>there's a `open-paren-in-column-0-is-defun-start' <bandali>i wonder how common bumping into this is <nckx>I have that set since Guix doesn't follow this convention but I don't think I actually use anything that needs it. <nckx>bandali: There are (/were?) some descriptions with a column-0 ‘(’. <mbakke>civodul: simply adding guile-final to the gc roots appears to have done the job! <reepca>I ran into that +issue+ behavior about four times before I finally got fed up with it and searched for an explanation <reepca>it seriously messes up paredit's navigation commands <mbakke>the test is still not finished, but past the provenance.drv <nckx>I've always refused to reflow descriptions to work around such a blatant bug. Emacs gets enough preferential treatment around these parts already ;-) I had no idea they tried to dress it up as a ‘convention’ though. <mbakke>"guix system: warning: at least 1240.7 MB needed but only 1231.6 MB available in /mnt" <civodul>gooding that adding guile-final helped <nckx>pkill9: Your guix-devel@ subscription was suspended due to excessive bounces. <bandali>thinking about it, this is probably why iirc `fill-paragraph' pulls an additional words to the beginning of the line before open parens <civodul>mbakke: provenance.drv comes from 'scheme-file', which uses gexp->file, which uses gexp->derivation, which uses %guile-for-build, which is probably guile-final <civodul>perhaps on master guile-final is pulled in in some other way <mbakke>maybe through the initrd; the initrd is actually Guile 2.0 on core-updates ***modula2 is now known as defaultxr
<mbakke>and the fact that (gnu system linux-initrd) fetches %guile-static straight from (gnu packages make-bootstrap) <mbakke>haven't bothered doing anything with it yet, but seems like it's about time! :) <nikita`>i think i just broke a package download in guix <nikita`>I'll fix it and tell you the new location, had to start making my server smaller / move stuff for financial reasons <civodul>yeah it's unfortunate that make-bootstrap.scm is used for both purposes <civodul>the initrd code should prolly have its own variant <mbakke>civodul: I actually tried and failed to update %guile-static to 3.0 before that commit, but had trouble porting the guile-relocatable and/or guile-linux-syscalls patches