<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'
<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>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...
<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.
<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
<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
<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>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.
<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?
<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>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`.
<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?
<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?
<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>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
<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>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.
<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?
<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>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 :-)
<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>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)