IRC channel logs


back to list of logs

<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/"?
<roptat>no, sorry
<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>The following build is still in progress:
<Blackbeard> /gnu/store/x5sw5gzqw0qir831azj4c60fkh4w2v90-emacs-org-roam-1.0.0.drv
<Blackbeard>why is it still in progress?
<Blackbeard>but also successfull
<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
<usney>hi rekado
<xelxebar>rekado: Thanks for appropriately interpreting my tiredness-garbled message about "the server". Hear anything from 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 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>alright, i'll see what i can do
<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>jsoo: ‘later tell …’
<nckx>sneek is a simple-minded friend.
<nckx>(sneek: botsnack)
<terpri>thanks jsoo, i'll take a look
<jsoo>nckx: ah! Thank!
<nckx>Np. ‘sneek: tell jessica …’ just means you're 13 and not talking to her.
<jsoo>ah ok
<jsoo>I’m irc new
<nckx>I don't know why that functionality exist. And sneek is just or (and #guile's) private bot, with its own quirks 🙂
<jsoo>it seems nice!
<jsoo>sneek: botsnack
<jsoo>noce bot
<nckx>Also completely undocumented AFAIK.
<nckx>sneek: what is sneek?
<sneek>Someone once said sneek is a good bot
<nckx>And right they were.
<jsoo>indistinguishable from magic :)
<raghavgururajan>Hello Guix!
<raghavgururajan>nckx Are you around?
<nckx>But working.
<raghavgururajan>Okay. Let me know when you are available. Thanks!
<Blackbeard>raghavgururajan: hi ٩(◕‿◕。)۶
<nckx>raghavgururajan: Tomorrow. What for?
<Veera>Hi guix
<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.
<raghavgururajan>nckx My doubts pertains to git.
<raghavgururajan>Veera o/
<Veera>initial start msg says started new session c1 for gdm; then removed session c1; gdm does not starts
<Veera>nckx: hi
<Veera>raghavgururajan: hi
<raghavgururajan>Veera That was an older bug. Are you suing up to date commit?
<nckx>raghavgururajan: Okido.
<raghavgururajan>nckx Thanks!
***apteryx is now known as Guest46862
***apteryx_ is now known as apteryx
<Veera>raghavgururajan: yes
<raghavgururajan>apteryx o/
<Veera>raghavgururajan: latest git pull
<raghavgururajan>Veera Hmm, thats odd. What DE are you using?
<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?
<raghavgururajan>Just check if gdm works fine with other DEs.
<usney>hi rekado_
<raghavgururajan>Veera An applicant, yes.
<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 (, guix will build them locally.
<raghavgururajan>usney Btw, by guix installation, do you mean installing guix on foriegn distro or installing guix system?
<usney>foreign distro
<usney>I am using debian testing.
<raghavgururajan>I see. In case of foriegn distro, check if substitues are enabled.
<raghavgururajan>Btw, did you use script or manuall installation?
<usney>yes I used the script
<usney>the script works fine
<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>usney Cool! Just make sure substitutes are turned-on. Refer to
<Veera>eh! gdm does not starts
<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>still doing some tweaks
<raghavgururajan>usney You will have to 'Application Setup'.
<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.
<raghavgururajan>Ture, lxqt gonna be sucessor of lxde.
<usney>tint2 is pretty cool.
<usney>At least it won't be developed by the original authors especially pcmanfm.
<usney>I really like spacefm
<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 a work in progress.
<usney>I think I am going to switch to this login manager.
<usney>it is command line based but looks similar to a graphical login.
*raghavgururajan uses dwm+dmenu+st+xfe
<usney>is xfe on guixsd?
<raghavgururajan>Yes, I just packages xfe last week.
<usney>I really like slax it would be nice to make a free software version.
<usney>perhaps even have an easier installation method too.
<raghavgururajan>Regarding xfe, if you get missing icons error, just restart.
<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
<usney>that's cool raghavgururajan
<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.
<raghavgururajan>anadon. Hmm, not sure.
<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.
<raghavgururajan>usney Profile manifests might just be right for ya ;-)
<usney>oh for the locales and other variables?
<raghavgururajan>No no, list of applications.
<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.
<raghavgururajan>Ah I see.
<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?
<apteryx>raghavgururajan: o/
<usney>you can use two factor authentication login screen? "login-duo - login wrapper for Duo Security two-factor authentication"
<usney>in gnu/linux now?
<raghavgururajan>apteryx How are you doing?
<apteryx>raghavgururajan: I'm good! Sleepy :-)
<anadon>What package file should facebook's "watchman" program go under?
<apteryx>anadon: what does this program do?
<anadon>apteryx: It watches a directory tree(s) for change to files and reports them.
<anadon>Maybe storage?
<guix-vits>Hi there.
<Blackbeard>can anyone help me with git am session?
<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>Or git rebase --abort.
<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.
<Blackbeard>nckx: apparently the problem is with whitespace
<Blackbeard>thanks for the solution :)
<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.
<anadon>nckx: Thanks
<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.
<nckx>*I do.
<nckx>vagrantc-pbp: Congrats!
<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?
<nckx>Hmm. You sure?
<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.
<vagrantc-pbp>e.g. maybe it wasn't an encrypted rootfs or something
<nckx>vagrantc-pbp: Initrd contents should be destroyed before pivoting to the empty ram-root.
<vagrantc-pbp>no, don't disable the password, just only ask it once
<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 ...
<vagrantc-pbp>somewhere in /proc or /sys or something
<nckx>Neither of which are likely to show up in last year's back-up, unlike /gnu 😉
<vagrantc-pbp>was an eye opener when i confirmed that was the case...
<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.
<vagrantc-pbp>you put all your keys on gitlab or something :)
<nckx>People would think it didn't exist and encryption was magic.
<nckx>And do stupid things.
<nckx>Them being people & all.
<vagrantc-pbp>despite some read forehead slapping moments, it also keeps life interesting :)
<nckx>vagrantc-pbp: So you're saying <> point 4 is out of date?
<nckx>I'm not familiar with Debian org, or where the up-to-date official stuff would be.
<vagrantc-pbp>i mean, it's documentation for Debian, chances are...
*vagrantc-pbp actually looks now
<apteryx>vagrantc-pbp: I think you are talking about this script:
<vagrantc-pbp>hmmm... updated mid-last-year
<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 😛
<vagrantc-pbp>admittedly, "just"
<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
<vagrantc-pbp>is there any cpio code in grub?
<nckx>I think your initrd privilege is the problem here, vagrant.
*vagrantc-pbp looks
<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
<vagrantc-pbp>nckx: i see
<nckx>That's my point.
<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>well, nothing's 100% secure :)
<vagrantc-pbp>alternately, you could read the keyfile directly off the filesystem, since you've already decrypted it
<vagrantc-pbp>and append the initrd there
<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.
<nckx>vagrantc-pbp: ☝
<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.
<apteryx>(in case of power outages)
<nckx>GRUB's cryptomount doesn't support reading a key file.
<vagrantc-pbp>apteryx: what's your threat model?
<vagrantc-pbp>ok, so usb stick only for passing via the initrd then.
<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.
<apteryx>glad you did :-)
<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
<vagrantc-pbp>but of course, you'd need userspace to do that
<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.
<apteryx>OK :-)
<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.
<nckx>brendyyn: Yes.
<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.
<guix-vits>Blackbeard: can you paste the definition?
<nckx>Blackbeard: To me that means that emacs-typit should install english.txt to its <out>/share/emacs/site-lisp/dict/english.txt?
<Blackbeard>nckx: oh I see.
<Blackbeard>this is the definition
<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.
<Blackbeard>nckx: thanks !
<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>brendyyn: You can ask them and/or point them to COPYING at <> which covers images. I think sirgazil made all the new screenshots so if they do need to be dual-licenced to something more hip they're the one to ask.
<nckx>First them = Wikipedia. Tired. Bed. Bye o/
<guix-vits>Blackbeard: typo: ``@code{emacs-tpyit}'' "typit"
<guix-vits>also 'a tpying game'
<Blackbeard>guix-vits: thanks! fixed
<guix-vits>Blackbeard: are you packaging emacs-mmt too ("module is missing err")?
<Blackbeard>guix-vits: yes! I already packaged that
<Blackbeard>I alread sent emacs-org-roam (which is pretty cool btw)
<Blackbeard>emacs-uml-mode the one I am testing right now
<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>and it asks me if I want to apply it
<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?
<defaultxr>guix gc ?
<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><a>'HTML, entirely on one page'</a> on returns 404
<guix-vits>at least for me B)
<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
<marmulak[m]>that sounds useful
<guix-vits>xfce-desktop-service is "deprecated", btw. seems that service-type is a new "form".
<marmulak[m]>yeah, this page seems to reflect that service-type is correct
<marmulak[m]>but it doesn't match the example in the gray box
<rekado_>the manual is wrong there
<rekado_>it should be (service xfce-desktop-service-type)
<rekado_>or (xfce-desktop-service), which is the deprecated form
<marmulak[m]>what was meant by adding -type?
<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]>well I found one in /store so it's all good
<guix-vits>thanks Blackbeard.
*marmulak[m] uploaded an image: guix-system-manpage.png (47KB) < >
<marmulak[m]>this manpage for "guix system" looks to have some formatting issue
<guix-vits>marmulak[m]: +1
<marmulak[m]>(1+ marmulak)
<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> deployed0
<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...
<guix-vits>Blackbeard: -- works
<janneke>sneek: later tell jeko, does instrumenting the (guix-infect) script in gnu/machine/digital-ocean.scm help?
<sneek>Got it.
<janneke>sneek; botsnack
<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..
<guix-vits>Blackbeard: cool.
<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?
<guix-vits>mroh: interesting question, btw...
<eric-guix>The new release of guix well be libreboot compatible>
<guix-vits>raghavgururajan: ^^^ (hi)
<xelxebar>eric-guix: Do you mean by supporting different coreboot payloads? Currently, with libreboot+grub, guix should Just Work, no?
<civodul>hey hey!
<civodul>look, there are hyperlinks in code snippets:
<brendyyn>thats more than simply cool
<jonsger>civodul: amazing. I think we should add some more and more verbose examples to the manual. That is pretty cool :)
<bdju>yes that is quite 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>I found an issue in the rc2 system intaller, which I found reported here:
<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?
<guix-vits>reepca: ("two hours")?
<guix-vits>* idk
<guix-vits>reepca: `sudo sysctl -a|grep keepalive`
<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, you have 1 message!
<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
<janneke>jeko: ah, well i supposed that it's the infect script that's failing
<jonsger>There seems to be a new choice for running graphic cards with free drivers and without proriatary firmware:
<janneke>jeko: can you see on the server if the script was executed?
***andre_ is now known as AndreOc
<AndreOc>hi all
<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
<janneke>hello AndreOc
<AndreOc>Hi janneke
<AndreOc>So I used this video as my tutorial
<AndreOc>After "bash" 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>Then I ran into this problem which I solved in this way (at 2.6.1)
<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).
<civodul>AndreOc: you can still authorize substitutes, see
<jeko>janneke: the droplet on Digital Ocean does not exist. I may have missunderstood. Do I have to create it by myself ?
<drainful>No it should be created
<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?
<AndreOc>civodul: thank you, busy with it
<jeko>drainful: i'm interested for some point of view as well haha
<jeko>I made a gist of my machine declaration if some of you have time to have a look...
<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
<drainful>low tech
<smithras>jonsger: thanks!
<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.
<AndreOc>please excuse me, I don't know what the "installation prefix of Guix" is -
<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>red__, is that jami from guix?
<AndreOc>roptat: thank you very much :-)
<roptat>is this guix on a foreign distro or the Guix System? what does "echo $GUIX_LOCPATH" give you?
<red__>guix system
<roptat>also, what's in $LANG for you?
<red__>"echo $GUIX_LOCPATH" says "echo $GUIX_LOCPATH"
<red__>UPS SORRY
<red__>run current-system locale
<red__>and language would be en_CA.utf8
<roptat>can you check what version you have in /run/current-system/locale?
<red__>yes its the 2.28
<roptat>have you run guix pull in the last few months?
<red__>i did today
<roptat>and jami was installed after you pulled?
<red__>it was already installed
<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?
<apteryx> j
<red__>i can try and do that, although i have had the same problem also when i had the 2.29
<J[m]>apteryx: hi
<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
<red__>im on it right now
<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
<roptat>utf8, sorry
<civodul>interesting post:
<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__>thanks roptat
<civodul>what's up there?
<civodul>we have a problem
<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.
<civodul>yes, not clear what's going on
<civodul>it's worrisome, though
<cbaines>The latest revisions look to have been processed successfully on
<cbaines>But looking at the logs, some of the channel-instance derivations have failed:
<cbaines>Well, ignoring MIPS, the armhf-linux compute guix derivation failed, because http-parser failed to build
<cbaines>This is the http-parser change:
<cbaines>The guix-master and guix-modular-master jobs on seem OK
<pkill9>can someone upload a qemu image of guix running on the hurd plz?
<pkill9>aaactually i should just make one on a VPS
<pkill9>why do i not use VPS's more
<mbakke>civodul: it was because libgit2 failed on aarch64 and armhf and broke 'guix-modular-master':
<mbakke>*perhaps it was ^
<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>Updating channel 'guix' from Git repository at ''...
<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>cbaines: Yes, both those are set:
<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>clock, not lock.
<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>(unless the clock is newer)
<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'
<vagrantc>t do anything
<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
<vagrantc>yeah, i've seen various fake hw clocks
<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>J[m]: hello!
<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>nckx: same issue, though
<vagrantc>i tried using the https reference for openntpd, but that seemed to guarantee that the clock never synced
<vagrantc>though i tried as a reference ... mybe their clock is ~5 minutes slow
<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.
<reepca>by the way, if anyone happens to have free packaging time, updating emacs-magit would be great. I'm still suffering from
<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...
<apteryx>nckx: these patches make it possible to mount LUKS volumes with key files:
<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’.
<apteryx>perhaps we could add a variant GRUB package built with those patches. Arch does it:
<jayspeer>hello #guix
<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.
<Blackbeard>Hello ٩(◕‿◕。)۶
<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>Hullo Blackbeard.
<nckx>apteryx: True.
<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>nckx: hey !
<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> -<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
<Blackbeard>And decided to wait until they are approved
<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.
<Blackbeard>nckx: oh i didn't use git send-email
<nckx>That's probably fine.
<nckx>Git is great
<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
<Blackbeard>nckx: ok. Thanks!
<Blackbeard>Then I guess I'll keep sending stuff
<nckx>Blackbeard: ’git send-email -1’ 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.
<Blackbeard>nckx: thanks ! That sounds easier
<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.
<vagrantc>oh, it's 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
<apteryx>these tests take ages
<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).
<apteryx>it's all very expensive
<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
<apteryx>mbakke: good job on by the way :-)
<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:, the patch is the one identified with: '[PATCH 1/5] gnu: tests: Reduce the time required to run the system'
<apteryx>s/system/system tests/
<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
<mbakke>cbaines: interesting, thanks
<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?
<anadon>Good afternoon, guix
<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>lfam: they get updated together
<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
<dustyweb>and on the opposite end of microkernels:
<civodul>terrible :-)
<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>which test?
<civodul>installed-os is fine?
<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
<civodul>prolly guile-3.0.2 here
<civodul>now, why is it missing...
<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?
<civodul>in the initrd? no
<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>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
<mbakke>civodul: will try that, thanks
<Blackbeard>I have a problem with my config.scm
<Blackbeard>I want to have gdm autologin
<Blackbeard>I did this
<nckx>Blackbeard: set (default-user "username")
<Blackbeard>but I am getting this error
<nckx>That's not related.
<Blackbeard>nckx: ah!!
<Blackbeard>that makes sense
<nckx>GDM needs to know as whom to log in. But that syntax error… oh boy.
<nckx>Oh, got it, it's a classic.
<Blackbeard>nckx: should I just change to slim?
<Blackbeard>i think you suggested slim
***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 …).
<nckx>It's not a GDM problem.
<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..
<bandali>also, M-x check-parens RET :-)
<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
<civodul>yup, that's terrible
<lfam>Wow, I figured it would be solid
<bandali>breaking in what sense?
<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.’
<nckx>That is, erm
<nckx>classic emacs.
<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 ‘(’.
<bandali>nckx, interesting
<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
<mbakke>very impressive :-)
<reepca>it seriously messes up paredit's navigation commands
<bandali>i see
<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"
<mbakke>close call
<civodul>it may eventually fail :-)
<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
<civodul>what's the deal?
***modula2 is now known as defaultxr
<Blackbeard>I could not autologin with gdm.
<Blackbeard>perhaps this is the problem
<mbakke>civodul: it's a combination of this commit:
<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 mean you have the cache
<nikita`>I'll fix it and tell you the new location, had to start making my server smaller / move stuff for financial reasons
<civodul>mbakke: oh right, i remember
<civodul>yeah it's unfortunate that make-bootstrap.scm is used for both purposes
<civodul>the initrd code should prolly have its own variant
<nckx>nikita`: Which package?
<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