***chrislck_ is now known as chrislck
<fnstudio>hi :) i'd like to ship my project with a guix.scm file for other contributors to be able to reproduce an exact dev environment <fnstudio>the example starts with `(use-modules (guix) ...` <OriansJ>using the example provided in the manual with one minor change does not work: guix archive --export -r gnutls@3.6.12 | ssh Target guix archive --import ; What can I do to get this to work? <vagrantc>lfam: wow, 10 minutes is very ambitious timeout :) <lfam>I think it's a mistake somewhere, vagrantc <vagrantc>lfam: did you end up booting the timeout, perhaps mistakenly wrong number of zeros or wrong unit or something? <lfam>I haven't touched it vagrantc <lfam>I didn't get any replies to my message on the subject from a couple days ago *vagrantc needs to update the wip-pinebook-pro branch to 5.10.x <vagrantc>lfam: yes, i figured it was a mistake :) <fnstudio>hm... except that i didn't think i needed a remote url to fetch the package, as i'd like to simply use the code contained in the repo, without having to hardcode the url <fnstudio>(sorry if this is obscure, i was following a bit of a stream of consciousness) <mhj[m]>Just wanted to say thanks to lfam and crew for helping me get started down this Guix journey. It's been pretty fun, and I'm figuring out more things as I go along :D <lfam>We're happy to help mhj[m]! Welcome aboard <lfam>fnstudio: I'm not sure if they are around, but I think that davexunit was the expert on using guix.scm <lfam>fnstudio: Are you talking about the source URL of the package? <lfam>If so, Guix accepts URLs on the local filesystem <mhj[m]>I might have to reinstall the system, and I plan to use btrfs and snapshots. I found a snapshot script on the gentoo wiki that looks promising. So yeah. Once I have that setup, I'll feel 100% better cuz then I'll have a great filesystem to go along with the great OS :D <fnstudio>lfam: yeah, i'm trying to add a guix.scm file to a proof-of-concept-like little program that i hacked together <lfam>It would be awesome to integrate btrfs snapshots into Guix System, like an 'fs-snapshot-service' <lfam>There is code for SUSE's snapper on the mailing list <lfam>I can get confused when thinking of the multiple levels of filesystem snapshots, "regular" backups, Guix rollbacks, etc <lfam>Also different levels of deduplication, occuring at each of those places <lfam>It would be cool to integrate all of it someday <lfam>And there is compression at each level, too <mhj[m]>True, maybe if there was a good GUI program that could helpfully layer it and date it accordingly, it wouldn't be like a maze to navigate through lol. <lfam>Oh, I think snapper is great and every OS should have something like it <pretzel>For (build-system haskell-build-system) , what's the difference between ... in (package (source (origin (sha256 ...)))) and (arguments `(#:cabal-revision "0" ...)) ? E.g. for cabal-install. <mhj[m]>Very true, Apple does have that, and I wonder about the future of that system. I thought they were going to end up going with ZFS, but instead they decided to use their own solution for a filesystem, and now they're doing their own custom chips. Well, that's Apple for ya lol <atkka>what is this bootloaders module for? (use-package-modules bootloaders) <atkka>I see it in some configurations but not others, is it needed for grub-efi? <vagrantc>i would think most systems need a bootloader, although there are some corner-cases where guix might not provide the bootloader directly but just generate a configuration file for a bootloader to use <atkka>I was just wondering if it is requisite for (bootloader grub-efi-bootloader), it doesn't appear to be needed for legacy grub <atkka>vagrantc: is the WIP pinebook pro coming along well? I may pick one up to play with guix on it <vagrantc>atkka: still needs a bunch of kernel patches and usb network adapters ... but works for me <vagrantc>should have an update for linux-libre 5.10.x pushed soon <atkka>thanks, if I can get my hands on one and get my guix skills up to snuff, I would be more than happy to pitch in somehow <vagrantc>main thing it needs is more people trying to get the patches upstream at this point ... though a lot of the patches in wip-pinebook-pro aren't really upstream quality <atkka>yeah, I can't say that anything I could put out would be either <vagrantc>part of why i've never pushed it upstream... <atkka>does the pbp show promise though, is it pretty open or have the potential to be? <atkka>lfam: success! I installed guix, super bare-bones the manual way <vagrantc>the usual firmware problems with wifi ... i suspect the external display option requires non-free firmware or something like that ... the keyboard also has firmware and i haven't been able to find source for it, although it is allegedly open <vagrantc>better than many, but still plenty of issues <atkka>huh, I thought the pbp was about as blobless as possible these days <atkka>thanks for the info though, I may have to go the refurbished thinkpad route <vagrantc>the LCD display works without firmware though ... <joshuaBPMan>atkka (use-package-modules bootloaders) is needed for installing grub <atkka>joshuaBPMan: are you sure? I just installed and booted without it... <atkka>I used the bare-bones.scm example <joshuaBPMan>at least there is no (use-packages-modules bootloaders) <vagrantc>must be a hidden default to use grub or something <atkka>I was able to get it installed without hanging by editing the bare-bones.scm and adding my efi uuid and changing the bootloader section to grub-efi-bootloader <vagrantc>usually guix is pretty good about not making assumptions like that and documenting the defaults <atkka>using the desktop.scm or lightweight-desktop.scm would hang when fetching files from the ci <atkka>so can I build up from this base system then generate a config from my edited system using guix? <vagrantc>though you're likely to hit the same problems as you add things that pull in the packages that are hanging on the ci ... <atkka>but it seems like its just me though... I wonder why <vagrantc>guix definitely sits there not giving much feedback from time to time as it calculates this-or-that <atkka>it will just sit at a file forever <atkka>last time it was fetching cdparanoia and just hung at 71% for 30 minutes <atkka>ctrl-c and retrying gave me a guix-daemon socket error <joshuaBPMan>atkka: I use sway. That generally does not need to pull down as many files. You might have good luck with that. <joshuaBPMan>atkka: You can also just specify that you want to build everything from source. <atkka>now that I have it installed on bare-metal it will be fun to dig in <atkka>should make troubleshooting easier I hope <atkka>anyway, its progress and motivation <atkka>I use dwm myself, how does it work being configured by editing the source? can I feed guix my own when building it? <joshuaBPMan>vagrantc I'm working on a sway service type. I've got the data-structures mostly done. <vagrantc>i typically just login from the login prompt and "exec sway" <joshuaBPMan>atkka what do you mean? "how does it work being configured the source?" <vagrantc>atkka: guix excels at building from source :) <atkka>there isn't a configuration file for dwm, it is customized by editing the source then recompiling <vagrantc>dwm requires all features to be compiled in and doesn't take run-time arguments or configuration, from what i recall <vagrantc>guix is one of the few environments where dwm might make any sense :) <atkka>sweet, I use a lot of tools like that <atkka>vagrantc: so I can tell guix to use my version of the source when building? <vagrantc>atkka: certainly. that's pretty much a design goal of guix, as i understand it <atkka>oh ok, I had heard there were workarounds for software like this, don't remember if it was nix or guix tho <atkka>but I'm ready to dive in to guix and guile, thanks for the help everyone! <joshuaBPMan>vagrantc I have a little one liner in my .bash_profile that starts sway for me. But I read a blog post from one of the guix developers about what would happen if your computer caught fire today? How long would it take you to reset up your development machine? I think it makes sense to config your entire OS in one file. <vagrantc>joshuaBPMan: i'm pretty happy with my system-config.scm :) <atkka>ok, so I used the bearbones.scm as a base, no certs so git pull is broken <vagrantc>as guix shoudl reference the certs directly, i thought <atkka>guix pull: error: Git error: the SSL certificate is invalid <vagrantc>i hear you ... i've had it happen too sometimes <vagrantc>never quite understand what triggers it ... <atkka>do I need (use-package-modules certs) and configure nss-certs somewhere? <vagrantc>let's encrypt recently updated their signing certificates ... maybe le-certs needs to be updated <vagrantc>or at least, they deprecated some of their old root certificates... <atkka>ok, guix pull is broken for me but guix install nss-certs is working? <vagrantc>the certificate verification dances are always mysterious to me <atkka>ahh crap, guix install has hung on me, first thing I try to install <joshuaBPMan>Because dwm is customized through editing its source code, it's pointless to make binary packages of it. This keeps its userbase small and elitist. No novices asking stupid questions. <joshuaBPMan>atkka hmmmm. I wonder how one would go about debugging that. <atkka>joshuaBPMan: I cancelled with ctrl-c and re-ran guix install nss-certs and its chugging right along again... <vagrantc>sounds like transient networking issues... <atkka>I dunno, it has been an issue on two completely different computers that run other flavors of nix all the time <atkka>but it also seems localized to me, so I dunno <atkka>I have 3 computers running right now, a kubuntu box, alpine box and guix box, same switch and router <vagrantc>oh wait, the substitute servers don't do ipv6 anyways <vagrantc>it's probably something really annoyingly tiny. :/ <atkka>I dunno, I can torch the interface later though <atkka>trying to figure out my ssl certs <OriansJ>looks like I have no choice but set up a terminal server to work around guix export/import <OriansJ>m6rfpvm4v13nr7jc5bw8z4yib2382zs3-zstd-1.4.4.tar.gz is now a problem for those doing guix pull without substitutes so one may wish to make a copy from their gnu store to put for download efraim ***krkini is now known as kini
<atkka>to keep your system up to date you have to guix pull followed by guix system reconfigure for root and each user? <vagrantc>you can just do guix pull as a user and use sudo for the reconfigure <vagrantc>basically: guix pull && sudo -E guix system reconfigure /path/to/config.scm && guix upgrade <vagrantc>pull updates the list of available packages, system reconfigure upgrades the host operating system, upgrade updates the installed packages in the user profile <vagrantc>i guess "sudo -E" can just be "sudo" now, though old habits are hard to break <atkka>so you never have to pull as root for anything then? <vagrantc>there are even more complicated workflows, but that's the basic way of doing things :) <vagrantc>yeah, there's not really a compelling reason to ... unless you don't trust the user's guix with root access <vagrantc>though even then, why do they have sudo? :) <atkka>its just me, I'm just wondering why that page mentions root under the note <atkka>to explicitly update root's guix use sudo -i <atkka>makes it seem like its necessary <mhj[m]>I didn't realize you needed to do "guix upgrade" as a normal user after the host upgrade via sudo. Oops. I guess the manual didn't mention anything about user upgrades, and assumes you only use declared packages? <vagrantc>atkka: there are different ways and preferences <atkka>ok, I just don't want to leave anything unsecured and want to follow "best practices" <vagrantc>mhj[m]: that's if you use things like "guix install" to install packages in the user's profile <vagrantc>on a multi-user system it allows the users to upgrade independently of the rest of the system on their own schedule <mhj[m]>When I reinstall this system I'm gonna declare most packages because I just prefer to organize everything under one file if possible. I blame Emacs's Orgmode :) <atkka>I was able to reinstall and fix my ssl issues but every time I deal with the guix package manager it hangs at some point still, at least now its letting me resume, still frustrating though <atkka>gotta be my networking hardware, I'm going to wipe my alpine box and try on there <mhj[m]>Hope that works atkka ! One this machine, which is the only machine that Guix works reliably on, the networking was terrible till I messed with modprobe lol <atkka>mhj[m]: thanks for the support! <vagrantc>fwiw, i updated the wip-pinebook-pro branch <mhj[m]>Cool. I have a PBP. Would love to have Guix on there too <vagrantc>there's a linux-libre-pinebook-pro kernel that i last tested with 5.10.9 ... i'm not expecting issues with 5.10.10, but building now to be sure <vagrantc>if someone could help remove the non-essential patches, maybe we could push it to guix master... <vagrantc>i removed one that overclocked the CPU ... which might be nice, but not worth the risk <lfam>What sort of help do you need? <vagrantc>need someone with a pinebook pro to systematically test the ~25 patches and see which can actually be removed ... might involve a bit of rebasing <vagrantc>i could do it, but usually by the time i get a working kernel to push i'm tired :) <vagrantc>someone did a quick look-over and mentioned all the ones they thought could be removed, and i attempted that a while back without success <vagrantc> 31 files changed, 4247 insertions(+), 78 deletions(-) ... though 3000 of those insertions are a kernel config <anadon>If anyone is on, are there directions somewhere to install to a disk from a live, different OS? <vagrantc>hrm... the u-boot installation doesn't seem to be working <atkka>vagrantc: it helps if you install the right bootloader <vagrantc>well, fortunately, i had the "right" bootloader installed from another OS :) <atkka>haha, my friend says that crap to me all the time <atkka>wow, so my 2007 macbook and 2015 xps must not work with guix, I used the installer on an alpine "NUC" clone and it worked fine, with encryption (though grub keymap was wrong), no hangs when fetching from the ci either <vagrantc>wow, for some reason, even though i've changed all the patches ... it's not buildign linux-libre-pinebook-pro again ... hrm. *vagrantc suspects soemthing odd with ./pre-inst-env <atkka>hint: after setting PATH, run hash guix to makes sure your shell refers to 'home/foo/.config/guix/current/bin/guix' <atkka>this hint was from issuing guix pull, what exactly is it saying to do? <vagrantc>"hash guix" tells the shell to forget about the last known path to guix and refresh it's cache of known binaries <vagrantc>otherwise, you end up with bash calling the old guix <atkka>ok, did guix pull set the PATH and I need to run hash guix or do I need to do something with the PATH <atkka>I did run hash guix and there was no feedback <vagrantc>ok, i have a local commit from wip-pinebook-pro in which i basically just remove a lot of patches in gnu/packages/linux.scm for linux-libre-pinebook-pro ... and "./pre-inst-env guix build linux-libre-pinebook-pro" returns the same package with way more patches <atkka>ok, sounds good, lots new stuff with guix system but its starting to come together, I feel like I'm new to linux again! thanks again for all the help the last couple days <vagrantc>i even used guix time-machine against the new commit, and it still returns the same kernel... <vagrantc>maybe this is a sign i need to stop and do something else with my evening :) <atkka>vagrantc: maybe, I have had to walk away a couple times :) <vagrantc>ok, i edited the file again, and now it's building <vagrantc>actually, this is a good test ... no patches, just the kernel config <atkka>I set guix up with luks this time, I get asked for my password before grub (still has the bios image) then I get to grub and select my entry, then it asks for luks password again. Why would it ask twice and once "before" grub? <atkka>the first time it asks it takes a long time to unlock as well <atkka>hmm, I usually use 3 partitions for UEFI+LUKS setups, I did 2 partitions this time, maybe that's why <atkka>I guess this way I actually have encrypted boot, which is nice <apteryx>atkka: congrats for the successful install! Enjoy your Guix System :-) <apteryx>atkka: that's normal; the /boot directory is on the main partition, which is encrypted <apteryx>so GRUB needs to prompt an initial password to even fully load itself; then when the kernel starts it prompts again. That's my understanding. <anadon>apteryx: Is that why Ubuntu's implementation of full LVM encryption has a separate /boot partition? <atkka>apteryx: Thanks! Regarding the encrypted boot, I can avoid the second password by setting up crypttab/grub I think <atkka>unfortunately the first prompt asks for my pass before my keymap is activated though.. <apteryx>right, that's currently a known issue. May be difficult to fix, I haven't investigated. <apteryx>You can do the usual clever trick: use multiple passwords, one for each layout <apteryx>LUKS supports up to 8 passphrases, IIRC. <atkka>apteryx: that is a clever workaround, thanks I'll do that <atkka>or maybe a password plus keyfile ***sneek_ is now known as sneek
<firstlove>Hi, I cannot find any pkg-config via pkg-config --list-all, what should I do? <biotim>probably need to set PKG_CONFIG_PATH, like `export PKG_CONFIG_PATH="$HOME/.guix-profile/lib/pkgconfig:$HOME/.guix-profile/share/pkgconfig:$PKG_CONFIG_PATH"` <pretzel>Okay, hackage package tarballs shouldn't change, but their "metadata" might. Hence, both source hash ... in (package (source (origin (sha256 ...)))) and metadata hash ... in (arguments `(#:cabal-revision "0" ...)) are needed. <PurpleSym>Is there a reason `guix environment` and `guix package` generate different profiles when handing them the same packages? I see the manifests are different (environment is missing provenance information). Is that the reason? <civodul>PurpleSym: missing provenance is definitely a reason <civodul>but that should be the only difference <PurpleSym>Yeah, everything else in the directories is the same. <avalenn>what is the use of provenance information? <PurpleSym>Can I pass that manifest to launch-environment/container or is that a different data structure? <civodul>PurpleSym: perhaps you should explain the context a bit? <civodul>i mean, we could always add an option to turn on/off provenance info <civodul>but perhaps there's also a way that would allow you to avoid fiddling with store file names <PurpleSym>Ideally I’d like to start an environment from a profile generated by `guix package -m manifest.scm -p /path`, civodul. I.e. something like `guix environment -C --from-profile /path` <PurpleSym>(A containerized environment, to be specific.) <civodul>but then, why not use "guix environment -C -m manifest.scm"? <PurpleSym>Because the profile differs from `guix package -m manifest.scm` (see above) and thus has to be re-generated. <PurpleSym>Thus I cannot use /path inside the container. <civodul>yes, but why is regenerating a problem? it should be rather fast? <civodul>another option is to use "guix environment -m manifest.scm -r ./profile" <civodul>and then "guix environment -C -m manifest.scm" <PurpleSym>True, that could work, but I lose easy rollbacks. <civodul>if manifests.scm is under version control, roll back = git checkout HEAD^ + guix environment -m manifest.scm <PurpleSym>Ah, now I remember why `-r` is not a good option: It’s not atomic. I.e. I have to remove the symlink, before I can re-generate it, otherwise `guix environment` fails. <zimoun>About “guix git log” and Outreachy, I have Guile question: is it possible to have a «stream» in Guile (as Python ’yield’)? To avoid to walk all the list/tree if you need the first ’n’ elems as “guix git log | head -n5’. I have seen ’(ice-9 streams)’, is it usable? <civodul>PurpleSym: ah, that could be fixed; but i think we should also look at the broader usage scenario <civodul>zimoun: yes, i'd recommend (srfi srfi-41) instead of the other one <zimoun>civodul: haha! Thanks, I have been «lazy» to click :-) <raghavgururajan>In Guix System, both root and user are missing GUIXPROFILE env-var in the output of `env`. Bug? <civodul>raghavgururajan: no, GUIX_PROFILE is not meant to be an exported env var <raghavgururajan>civodul: But when I install foo and run foo, I get command not found. Until I manually export that env-var as mentioned by 'hint'. <civodul>the hint tells you to set the variable, not to export it as an env var <civodul>(shell variable vs. environment variable) <raghavgururajan>I think it happens when I do system reconfigure and have not rebooted yet. <raghavgururajan>During this time, if I install anything, i cant run it until I manually set variable GUIX_PROFILE. <raghavgururajan>I am so confused. After guix package transactions, I sometimes I get the hint and sometimes I dont. when I get, i cant run the installed program until I manually set variable. If I dont get the hint, things work just fine. <PurpleSym>civodul: Yep, I feel it’s weird to have two commands (package and environment) that do kind of overlapping things, i.e. generating profiles in different flavors. I was imagining something like `guix enter $(guix profile -m manifest.scm)`/`guix enter -C /profile`. <zimoun>about ‘guix load-profile’ by Roel. <zimoun>civodul: I will try to give a look at export-manifest in the coming days… if you give a look at the option’s hint patch. :-p *raghavgururajan waits for his email to go through guix-devel <civodul>raghavgururajan: could be! lvm-device-mapping is quite new <civodul>since the switch to Guile 3.0.5 i sometimes see the dreaded: "GC Warning: Repeated allocation of very large block (appr. size 69632):" <civodul>it just happened to me during "guix pull", right after the phase where Git checkouts are updated <wingo>if rr works for you and you have a likely case that reproduces it, you could "rr record" *civodul pushes onto stack <roptat>civodul, there seems to be an issue with the website, some sentences are not translated on guix.gnu.org/fr, but they are locally (after I generated the .mo file) <roptat>I know that I pushed a broken .po file at some point, but I've fixed that yesterday <apteryx>Am I the only one to see slow download speeds from ci.guix.gnu.org? <apteryx>but the substituter was printing: gcc-7.5.0-lib 59KiB/s 01:48 | 6.3MiB transferred <apteryx>I've 'sudo herd restart guix-daemon' and things are zippy again. <civodul>roptat: ah, weird! did you try building it locally using .guix.scm? <civodul>apteryx: in this case, you can guess that it was compressed on the fly, because the size is unknown (no Content-Length) <civodul>that contributes big deal to making things slow <civodul>this happens if you get a substitute before it's been "baked" <civodul>on-the-fly compression is also more sensitive to the current machine load <civodul>whereas sending a baked substitute is just sendfile(2) <apteryx>I see! The machine load must have been really high because 60 KiB/s is not a great compression rate ;-) <civodul>(though in this case it's unconditionally passed a low compression level) <roptat>civodul, that would be guix build -f .guix.scm, right? *civodul goes afk for a bit <roptat>looks like it will take some time :) <zimoun>is ’(srfi srfi-41)’ really used in Guix? I see 2 ’use-modules’ but no ’stream’ something. <roptat>don't we use streams in importers? <zimoun>roptat: that’s where use-modules srfi-41 are used, i.e., (guix scripts import json) and (guix scripts import texlive). But I miss how it is used. <roptat>I think it's used in the recursive importer, no? <roptat>I remember i had to fix the opam importer because there were some changes in the recursive importer <roptat>mh... I managed to build the website <rekado_>so these module imports could probably be removed. <zimoun>rekado_: thanks, I was looking for an example for ‘guix git log’ but the doc of srfi-41 is self explanatory. :-) <apteryx>has anyone even timed how long it takes to build the full rust bootstrap chain currently? (from 1.19) <apteryx>seems we should have a 'install-directory' procedure in (guix build utils) <apteryx>raghavgururajan: I guess you can file it, yes! Perhaps someone in the know will tip in. <raghavgururajan>apteryx: Since this is a booting issue, should I set the priority to IMP? ***fever is now known as Guest88407
<apteryx>I don't think so, it's quite new and not yet used at large, I believe, so unlikely to impact many. <Guest88407>I'm having trouble running jGRASP, a java application. I believe it's failing to find a usable font through fontconfig. <PotentialUser-72>Hello, I have installed Gnu Guix with i3 wm and xfce Desktop Environment last week. Also installed some programs like pavucontrol, midori, ungoogled chromium, simplescreenrecorder and hexchat. How can I setup hexchat to access this irc guix gnu group? <stikonas>PotentialUser-72: you juts need to start hexchat and login to freenode <raghavgururajan>apteryx: Cool! UNRELATED: Btw, if I use a separate home partition and mention that file-system under file-systems declaration, to mount it under /home/user, would there be a problem if there is already an existing /home/user directory with files in it? <iis>Client: HexChat 2.14.3 • OS: Unknown Distro • CPU: Genuine Intel(R) CPU U4100 @ 1.30GHz (1.22GHz) • Memory: Physical: 3.6 GiB Total (3.2 GiB Free) Swap: 3.6 GiB Total (3.6 GiB Free) • Storage: 37.6 GB / 455.5 GB (417.9 GB Free) • Uptime: 6h 35m 30s <iis>Hello everyone, I installed Gnu Guix last week, and I didn't know how to setup hexchat to access this group. Thanks for the help I received here. <iis>relating to Hexchat, what is the difference between Detach and Close ? <joshuaBP`>Hey #guix people! I am about to test my new sway-service locally. So excited! *roptat is trying to get the package descriptions translated on the website <apteryx>raghavgururajan: I think the mount will just shadow the existing directory <ngz>Hello. Can python-setuptools be updated on master (137 dependents) or is there a hidden bootstrap depedency? I am a bit surprised by the low number of dependents. <apteryx>ngz: setuptools come with python itself, so it's bundled and doesn't trigger rebuilds <ngz>Interestingly, the package I'm contemplating does not see bundled setuptools and require "python-setuptools" as a native input. I may have missed something though. Anyway, I can update it. Thanks. <raghavgururajan>> apteryx: raghavgururajan: I think the mount will just shadow the existing directory <raghavgururajan>I did system reconfigure with file-system with mount point as '/home'. As a user, all guix-profile content was not referred. The $HOME dir was empty. So I had to reverse system-generation. <Guest88407>I also tried running ghidra to see if the problem was unique to jgrasp and I got the same errors. Has anyone on Guix System gotten gui java applications to run? ***wielaard is now known as mjw
<raghavgururajan>Guest88407: You can try adding font-gnu-freefont and font-dejavu to packages list in config.scm <paulj>I am struggling with a simple guix / guile problem with my configuration. I have created a base-system config, which I intend to use with multiple machines. I load this into the machine configuration file with an inherit s-expr. This is extracts of the code in the base-system.scm file: <paulj>(define-module (base-system) <paulj>(define-public base-operating-system <roptat>please don't paste the whole config here, use paste.debian.net for instance <paulj>I won't post the whole lot here, for obvious reasons. In the machine config file, called zeus.scm, I have this: <paulj> (inherit base-operating-system) <paulj>sudo -E guix system -L ~/.config/guix/systems/ reconfigure ~/.config/guix/systems/zeus.scm --dry-run <paulj>ice-9/eval.scm:223:20: In procedure proc: <paulj>error: base-operating-system: unbound variable <paulj>hint: Did you forget `(use-modules (base-system))'? <paulj>It seems like it isn't finding the base-system.scm file, or not reading it. Both files are in the same directory, as you can deduce from the command. Am I missing something? <roptat>try this: guix repl -L ~/.config/guix/systems <roptat>there's probably an issue in your base-system.scm that's preventing it from being loaded <roptat>or, as the hint suggests, you didn't use (use-modules (base-system)) :) <paulj>I didn't show it, but the first lines in the zeus.scm are: <roptat>sure, then try loading the module in a guix repl, see what it tells you <paulj>Thanks - it is giving me errors for one the packages in the list - I will remove it and see what happens. <paulj>Thanks roptat - that was indeed the issue. I hadn't used the repl before - that's a good pointer for the future to help find problems. On this occasion, the original error message was perhaps not so helpful! <roptat>yeah, but the actual error happened too early for us to notice, so we can't really know what was really happening <paulj>That's clear (I wasn't complaining!)! ***wielaard is now known as mjw
<jgibbons[m]>hi guix, it looks like nm-applet doesn't have permissions necessary to create an ad-hoc wifi network. <lfam>jgibbons[m]: I recommend clarifying the problem and your goals. Do you want to create an ad-hoc wifi network? Or make it so that nm-applet can do so? And why you think it's a permissions problem? <jgibbons[m]>I want to make it so nm-applet can do so. I think it's a permissions problem because it says it doesn't have permissions. <jgibbons[m]>I was able to get around it by killing .nm-applet-real and calling sudo -E nm-applet-real <paulj>Could you please clarify this message for me: In procedure struct-vtable: Wrong type argument in position 1 (expecting struct): #<procedure keyboard-layout (name #:optional variant #:key model options)> <jgibbons[m]>But when I reset, it will revert to the old permissions. <paulj>I am not sure if it is fatal - I am using --dry-run at the moment. This is the keyboard entry in my config: (keyboard-layout (keyboard-layout "gb" "extd" #:model "thinkpad")) <paulj>I should clarify - I am calling guix system reconfigure... <paulj>Earlier I hadn't got past the problem with the missing package. <paulj>I don't get that error in the repl <paulj>Only when running the full command <lfam>Another option is to figure out if this task really requires root or not <jgibbons[m]>paulj: It doesn't make sense. "gb" should be a valid keyboard layout name. <paulj>I'll just check where this is used - perhaps I have a different issue... <apteryx>civodul: I'm going to push the unpack/repacking changes allowing single files, if you don't have an objection. I find myself relying on it more and more. <pineapples>Does anyone know the difference between the extra-special-file service and special-files-service-type one, usability-wise? Is there a strong argument shifting in favour of one over the other one in a system configuration? <paulj>Found it - I had the keyboard-layout defined in the base-operating-system structure, then used it in the system config. I guess the definition of keyboard layout shown above isn't visible in the structure inheriting the configuration, so it took the second keyboard-layout in (keyboard-layout keyboard-layout) to be a function. <lfam>pineapples: You should use extra-special-file <lfam>Otherwise, you'll need to manually respecify the things provided by special-files-service-type, which is part of %base-services <lfam>Namely, it creates /bin/sh and /usr/bin/env <lfam>The former is especially important <roptat>civodul, so this morning I was able to build the website with .guix.scm locally, and everything was translated. The website is still not up to date. Can you check? <phireh>So I'm trying Guix System in a VM and I just realized that there's not a /etc/config.scm file... are you supposed to write it by hand the first time? <jonsger>phireh: its maybe named different, maybe do a find /etc -name "*.scm" <lfam>phireh: Look at /run/current-system/configuration.scm <roptat>mh... I thought the VM images we provide had /etc/config.scm now? <lfam>Or, we should make it more clear that people should look at /run/current-system/configuration.scm <lfam>The thing is, do we have a mechanism in `guix system` to put a file in that location, '/etc/config.scm'? <lfam>Thanks for the sudo update nckx <phireh>Ok so I just looked, I have a configuration.scm but no .scm files in /etc <lfam>That file is the one that your VM was created with. You'll need to copy it somewhere else in order to edit it <lfam>Highly recommended to read the manual :) <roptat>lfam, oh 362bcdb1b076c8c46f71781add56dfbe532736dc <lfam>Maybe we should put it back, or publicize the new way more <lfam>I think we finally got to the point where everyone knows about /etc/config.scm <lfam>I hadn't heard of /run/current-system/configuration.scm until someone asked the same question recently, maybe a week ago <phireh>I was checking the manual just now, trying to look for cool features to test <phireh>I read that I'm not supposed to use things like groupadd but use the .scm file instead, right? <roptat>yeah, groupadd would only be temporary, until the next reboot I think <roptat>or the next reconfigure, whichever comes first <roptat>most of the sysadmin tasks (adding users, groups, changing configurations, etc) is done via the configuration file <roptat>the idea is that you don't run command that modifies the state of the system, instead you *declare* the desired state, and reconfigure the whole OS to get to that state <civodul>apteryx: re pack/unpack, sorry i've been busy these days; in which case do you rely on single files? <civodul>as i wrote, i think it's nice to have if we actually use it "frequently enough", but my impression is that we had few or no cases where we absolutely needed single-file origins with a snippet/patch <pineapples>I need to put a single bash script in the /usr/lib path for a rather unfortunate workaround that no amount of downstream patching will completely alleviate without the involvement from the upstream due to its complexity, and I figured that I can use extra-special-file to do that; however, the script in question needs to be marked as executable. I tried to employ a gexp->derivation and mixed-text-file but couldn't get it right, a <pineapples>s well as make it so that the instance of extra-special-file would use it. Is there a way to populate the said path with my bash script, and mark it as executable, without resorting to package declarations? <nij>Hello, I have an arch machine.. is it possible to remain using the arch kernel, but start using the herd init system? <sneek>nij, rekado says: There’s a CSV (and more) parser: guix install guile-dsv <civodul>nij: no; but if all you want to keep from Arch is the kernel, perhaps you can use Guix System and customize the kernel you want? <nij>I'm still on arch b/c it takes time for me to get used to it. <nij>The idea is to move there incrementally + slowly. <civodul>then one option is to use Guix on top of Arch <nij>Guix, the package manager? <nij>or you mean the full guix? <apteryx>civodul: It's useful for Emacs packages, or any other single file programs (C, shell, etc.) <nij>How about the Shepherd init system? Can I use it on top of arch? <lfam>nij: It's possible, but if your goal is to change incrementally, I don't recommend it. <apteryx>the current kludge would be: cloning the whole repo (wasteful) or adding the source as an input and copying it myself (a kludge) <lfam>nij: It would be a huge amount of effort to set it up, and you'd lose a lot of functionality <lfam>nij: If you want to adopt Guix incrementally, use it as a package manager on top of Arch <lfam>This is a tried and true method of getting hooked on Guix <nij>lfam: you'd recommend me getting used to the guix packaging system, and switch to Guix System directly after that? <roptat>nij, yes, the shepherd is much better integrated with the Guix System than any other distro <lfam>You can switch whenever you like. Guix System is nice but extremely different from Arch or other traditional distros <roptat>you'd need to package it for arch, find a way to use it instead of systemd, write lots of scheme for your services... <lfam>And shepherd is, frankly, simplistic in comparison to systemd, or even the long-gone ecosystem that existed around sysv <nij>I have another machine that's currently installed with the Guix System. <nij>However, it's still experimental, as I find many packages I want lacking. <roptat>the experience of the shepherd on arch would be very different from the experience of it on the Guix System <nij>I'm not advanced enough to package those by myself (YET!) tbh. <lfam>I think that, if your goal is move along incrementally and slowly, you should make the switch you understand how to make. If you are asking these questions, it indicates that you wouldn't be able to make shepherd work on arch <nij>roptat: I see. Thanks for the info! I won't try that on arch then. <lfam>You could definitely learn how to get there, but to do it right now would be a rocky road <nij>the first step: to use the guix package manager <lfam>You can use Guix as a package manager on other distros, and keep using the distro's native package manager as well <lfam>It's a smooth and easy transition, and well-supported by Guix <lfam>All the while, you have the familiar arch tools and workflow right there, in case something goes wrong with Guix <lfam>Not to mention a helpful IRC channel ;) <nij>This is why it's hard now :-( :: /dev/sda3 30832548 27738096 1505204 95% / <nij>I shouldn't have partite my disks into four parts.. <lfam>Do you use LVM or a filesystem with online resizing? <lfam>I don't think ext4 can be shrunk while mounted <nij>It's fine. I need to get my stuff organized too. Maybe I can reinstall every thing on my machine soon. <civodul>apteryx: but really, for Emacs packages, we've learned to live without it, no? :-) <civodul>there's a certdata2pem package (it's in Python, not C) <civodul>it's also single file, but no snippets <nij>But really, except being configured in LISP (<3), whatelse is cooler about Shepherd than systemd? <nij>s/configured/written+configured/ <lfam>With systemd, for better or for worse, you're limited to the service composition methods that are baked into systemd. They are extensive, and it may be good to be limited, but nevertheless, you're limited. Whereas with shepherd, you have a programming language at your disposal, and can thus do anything <lfam>The sky is really the limit with shepherd, and the long-term aspirations are way beyond the current state <civodul>you *can* do anything, but in practice shepherd does very little compared to systemd :-) <nij>so it's again the power of Lisp <3 <stikonas>you can even write systemd unit runner in shepherd since it's full programming language :D <lfam>It's nice that shepherd is integrated with package management. That's something that systemd will always lack <lfam>By the way, civodul, any luck on the staging branch? <civodul>i postponed upgrade of my profile because there were too few substitutes <lfam>It should be better today <civodul>missing libreoffice, inkscape, icecat <apteryx>civodul: python2 even; that's why I want to get rid of it ;-) <apteryx>it's only possible to use a single file in this case because it's using the trivial build system (the unpack phase would fail) <lfam>It is ... fascinating... that inkscape has been built for i686 before x86_64 <lfam>Well, at least those builds are pending rather than failed *civodul starts those manually on berlin <lfam>I'm having trouble deciding when the branch is "done". I'm confident that the major server / desktop applications are in good shape for x86_64. <lfam>It would be useful to get some advice from the maintainers about expectations regarding substitute availability for other platforms <cbaines>breakages are probably more important than lack of substitutes, they are related though <lfam>It's been difficult to distinguish them, especially for aarch64. At least, when we were virtualizing it instead of using bare metal, a huge number of packages failed to build on CI, but built okay on real hardware <cbaines>yeah, I realised the inperfections of emulation when I was trying to use QEMU to build stuff for arm <lfam>It's tempting to complete the branch and let things get sorted out on master <cbaines>I'm going to try again mixing emulation + native hardware with the Guix Build Coordinator, as I am clsoe to being able to force retries on native hardware, as well as using emulation, which should avoid all the retries using the same setup <lfam>This staging cycle has also exposed some problems that I think shouldn't delay it, especially with armhf <civodul>lfam: i'd say we should get coverage close to master on x86 (~80%?), and likewise on the other architectures <lfam>That would be a good goal civodul, but we aren't building for armhf at all anymore, and aarch64 is basically broken on CI <lfam>No, it was disabled, I think last month *civodul lost track of many things this month <lfam>And for aarch64, we had stopped using the overdrives, leaving us with emulation that appears to be faulty <civodul>but wait, we had stopped emulation too, after dannym's discoveries <lfam>Over and over again, some important package would fail to be built for aarch64, but efraim would built it successfully on their hardware <lfam>The overdrives weren't (aren't?) being used <civodul>does someone somewhere know what's going on? :-) <lfam>The aarch64 thing was discussed recently but I'm not sure of the status <civodul>would you like to email him + guix-devel for an update? <civodul>explicitly stating that this is a problem for staging <lfam>I'm feeling frustrated with the slow progress. I wonder if armhf and i686 are being used or ont <lfam>Like, I think they are valuable platforms (well, armhf anyways), but they need attention <civodul>these two arches are in a bad shape, but i think they're used a bit (i686 for old Thinkpads sometimes discussed here, and armhf for low-end ARM boards like the one i have) <lfam>The armhf board will be around for a long time. But the i686 thinkpads... how many are there? Just rekado's? <lfam>I'm going to take another weather report and write that email <civodul>BTW, "guix weather -m etc/release-manifest.scm" is also a good indicator; it says 80% for staging <lfam>I hope I get some replies this time <lfam>How did we get into this situation? It's crazy, like there is soooo much energy and work being done, but not much coordination <cbaines>Maybe for this round with staging, it's best just to not pay too much attention to what it says about things other than x86_64-linux <cbaines>*what ci.guix.gnu.org says about things other than x86_64-linux <lfam>Okay, I'll take that as permission cbaines ;) <civodul>"guix weather -m etc/release-manifest.scm -s x86_64-linux -s i686-linux -s armhf-linux -s aarch64-linux" says 75% <lfam>I would like some capable aarch64 hardware, either locally or available via the build farm, so I could test and fix things <lfam>Having shell access to berlin has been a godsend <civodul>from berlin you can still offload to the other architectures <civodul>re coordination, it's always been the most difficult task <lfam>Yeah, but it would be easier to have shell access to one of the overdrives <lfam>Yeah, that's true. I'm learning it all over again, it seems <civodul>that's also possible: you can add yourself to overdrive.scm and i'll happily reconfigure <civodul>lfam: but i think you're doing (unwillingly? :-)) a good job here <lfam>Thanks civodul, I'll do that <civodul>it's all about looking at the calendar and reminding people of what needs to be done <civodul>and yes it's often frustrating, but OTOH, if you take it as a role of "branch supervisor", it can also be kinda fun <cbaines>I'll hopefully get the overdrive machine I have up and running over the next few weeks as well <lfam>I'd like to buy one of those honeycombs but it's sadly not a good time to be buying unnecessary things <civodul>mbakke also did a great job with those branches, just not this time around ;-) <lfam>I applied at beagleboard.org for early access to their upcoming RISC-V boards <lfam>On our behalf, of course <civodul>we should buy whatever sounds good for the build farm, particularly ARMv7/AArch64 <lfam>I was thinking we should ask Debian what they use <lfam>We must have similar values <zimoun>civodul: thanks for reviewing. I do not understand what ’formatted-message’. Instead of (format #f (G_ …)) it is (formatted-message (G_ …)) that’s it? *apteryx pulls their hair on NIX_STORE_DIR again <rekado_>lfam: I retired the i686 Thinkpad and replaced it with an old x86_64 workstation; but my living room ‘server’ is still an old i686 netbook (remember those?) <lfam>rekado: You are requested to try updating it on the staging branch :) <rekado_>I … don’t know how to offload the builds to my x86_64 laptop <rekado_>the i686 netbook is too weak to build most things <lfam>Ideally, you'll get substitutes <apteryx>weird; in the build of a Guix unit test (ran in the test-env, which sets NIX_STORE_DIR), (%store-directory) returns /gnu/store <lfam>Let us know what's missing for you. `guix weather` says that we have i686-linux substitutes for 69% of packages on the staging branch, compared to 86% for the master branch <civodul>apteryx: there's NIX_STORE and NIX_STORE_DIR, and there's (%store-directory) and %store-prefix... <michel_slm>Hi folks. any ballpark figure on how long Guix (the package manager) itself takes to build? <michel_slm>trying to get it into Fedora and I've finally tackled most of the dependencies (they still need to be reviewed), and... the compile job has been maxing out my 4 CPU cores for the past 15 mins or so <michel_slm>(mobile Core i7, which is.... sadly not that powerful)