<singpolyma>sneek: tell jgart I see why -L doesn't work now. You don't require the modules in guixrus by their name but I guess assume they somehow end up squished into (gnu packages) which maybe channels do?
<sneek>jgart, singpolyma says: I see why -L doesn't work now. You don't require the modules in guixrus by their name but I guess assume they somehow end up squished into (gnu packages) which maybe channels do?
<eonn>jgart: I wasn't in a development environment, but I had just installed cl-asdf. Workflow would be a generous word
<jgart>ah ok, wdyt could be better about cl workflow in guix?
<eonn>jgart: Sorry, "workflow would be a generous word" as in, I myself hardly had a workflow.
<eonn>I am still a cl newbie, so I don't know if the issue was my own error or not. I'm thinking stumpwm just needed a hard reset rather than the soft resets I was doing to test changes to init.lisp, so not a real issue
<jgart>eonn, have you checked out the cl cookbook?
<eonn>I have it saved. I was referencing the Guix cookbook for the specific thing I was doing, since stumpwm's ttf support is a popular enough issue
<AndrewYu>Can I be assured that everything in the default repos are free?
<vagrantc>Invariant Sections, Front-Cover Texts, and Back-Cover Texts ... all things that seem at odds with the freedom to modify
<vagrantc>but, uh, that's probably kind of off-topic here ...
<eonn>vagrantc: RMS' defense of Invariant Sections was to protect nontechnical portions of the documentation (e.g. the GNU Manifesto in the Emacs manual). You're not supposed to just make any section you want invariant
<zacchae[m]><vagrantc> "all of them have justifications,..." <- You can still get the effect of the "right to modify" for any functional purpose. specifically, if a section say "history" is invariant, you can make a "history1" and move any pointers from "history" to "history1" for any programatic section (which is garunteed to be modifiable).
<zacchae[m]>so it isn't a contradition as long as all source code is seperately available under GPLv3 (which is either suggested by FDL or nessisary, I forget)
<jts>stderr is just installing the named package and none of its dependencies
<zacchae[m]>jts: what exactly is failing? did you set your guix environment up?
<jgart>zacchae[m], but is `guix hash` the command that *generates* it? I think not iirc
<jts>I'm on GuixSD and followed the manual, so yes. When I install eg emacs-ement by `guix install emacs-ement` is only installs emacs-ement and not its dependencies, emacs-plz and emacs-ts, nor theirs, curl etc
<jts>Doing a dry run with flatpak, it only installed Flatpak, too
<jgart>Hi Guixers, is there a way to pre-cache all the guix packaged binaries or a subset thereof so that if I need a particular package/library I can get it instantaneously when running guix shell on a server?
<jgart>The reason I ask is the following to give some context: I've been developing an app that launches jupyter notebooks in "the cloud" in guix containers. In other words, the user pastes a url to a git repo into (html submit form) containing the jupyter notebook and the app runs the notebook in a guix container from a server.
<jgart>The app auto-detects a manifest.scm in the root of the jupyter notebook project repository.
<jgart>So, the app builds the container and all the dependencies for the notebook specified by the manifest.scm.
<jgart>The issue is the following: Sometimes a manifest with 10 python dependencies or even less will take a long time for Guix to build a container with everything specified by the manifest.
<jgart>And, the user will have to wait all that time staring at the browser window until Guix is ready and has built everything. Then a redirect happens, and the flask app sends the user to their requested notebook in the browser.
<jgart>Though sometimes the wait time for guix to build that container will be so long that the browser will eventually time out.
<jgart>And, why I am interested in caching "the python world" on a server to take advantage of `guix shell --container`'s new "hot cache, in 0.1 second".
<jgart>Does this sound like a sane way to solve this container build waiting issue?
<jgart>A question related to this: Is there currently a convenient way to tell Guix to build "all python-* packages" and cache them? I realize caching happens by default with Guix.
<PurpleSym>jgart: You can get a list of all packages with `fold-packages` in Guile. Then you could pass them to `guix build`, which will either build or download substitutes.
<PurpleSym>(“Guix container” is `guix shell -C`, right?)
<jgart>I'll email you a room link. I think we've emailed before
<muradm>PurpleSym: definetly it is with dependencies, issue is, wine is getting built, probably due to some dependencies getting rebuilt, for instance now it started building qtbase.. (face palm) that will take ages
<dcunit3d>is it simple to connect to `guix repl` from geiser? i'm trying to edit scheme files with system definitions, then load them into the geiser repl to test them before I try building, but I'm having a hard time constructing the environment (i am used to having lein or deps.edn from clojure)
<dcunit3d>i've also tried just starting a scheme repl in emacs (without the guix repl environment). when i do that, i have a lot of inconsistency with modules/definititions being found.
<lilyp>there is a package for doing guix stuff with emacs and it does have a repl binding, but I'm not sure how up-to-date it is with newer developments in geiser
<dcunit3d>i have the guix package for emacs, but it doesn't have a repl command. i've only used it for the transient buffers. i don't have guix-scheme-mode or guix-devel-mode active in buffers. i'll look at the docs.
<dcunit3d>i've gottin the geiser repl to ingest my packages with (operating-system ... ) definitions, but each time i start a new emacs server, various different things are going wrong
<dcunit3d>i think the guix.el package doesn't load its geiser functionality by default, so i'm looking into that. thanks lilyp
<abrenon>so I tried to retrieve the theme files, package them separately to be able to reuse them in a work environment for our future presentations
<civodul>bricewge: "Function not implemented" sounds like you're trying to load libgit2.so linked with a different glibc version
<xelxebar>abrenon: I see. Providing too much yak shaving opportunity for you, I see :P Good that are holding off (at least temporarily).
<civodul>overall it looks like you just upgraded to the post-core-updates merge Guix, right?
<abrenon>but pdflatex won't find the theme, even though I managed to define a copy-build-system package that copies the files to the right directory, I can find them and they are exactly next to the official ones (Madrid, Copenhagen…)
<g_bor>civodul: progress on the failing home test: rerunning it on an elgoind enabled system really makes it go away.
<abrenon>xelxebar: it took a huge amount of will power (plus the concerned reactions of a good many friends: "but, just finish your presentation first, you'll have plenty of time to shave that yak later")
<g_bor>I have now reverted the addition of elogind, to see if it makes it fail again or not
<bricewge>civodul: I'm not sure, I recall I did the upgrade in december already. But it could be.
<g_bor>Once that is done, I will update the bug description with the relevant info
<bricewge>So i should just do "guix pull" and try again ?
<civodul>bricewge: yes, the merge was end of December, so just make sure everything you use is from current Guix
<civodul>if you use "guix shell -D guix" for instance that should be all fine
<Guest8>I copied my ~/.gnupg and /.password-store from my old OS, but I am unable to decrypt my passwords with `gpg --decrypt`. I get an error for not having a pinentry program but I did install pinentry. I was thinking that because pinentry is installed in ~/.guix-profile, gpg-agent might be confused so I ran `gpg-agent
<Guest8>--pinentry-program=/home/nick/.guix-profile/bin/pinentry` but the problem persists. I know that the key is present and working though because if I open one of the .gpg files in emacs I am prompted for the key password and can view it in plain text as expected. Here is the relevant information. https://dpaste.com/5E863KSXQ
<jpoiret>do you have a pinentry-program line in gpg-agent.conf?
<nckx><gpg-agent might be confused> Yes, you generally need a pinentry line in gpg-agent.conf. I've never tried invoking it manually, but are you sure there's no previous gpg-agent still running?
<nckx>civodul: Right. I'm certainly not claiming my approach is meaningful :-) It was a quick script written in a fit of annoyance. I also suspect that randomisation leaks more info than just rounding to, say, the previous midnight, maybe I should do that.
<vivien>So I’m convinced now, I will start to gradually replace all my git+guix packages with a new form: a "main" branch that contains the code, and an unrelated "guix" branch that contains the channel code.
<singpolyma>vivien: why not a guix.scm for use with guix shell?
<kaelyn>Random question (of curiosity): why does rebuilding the Guix system (without substitutes) include building 5 or 6 different ghc versions? I've been trying to update a newish Ryzen laptop where the substituter is having issues (its last update was around the time the "expected exact integer" issues were popping up with the subsituter), and it has been building for two straight days now. While checking in on it over that time, I noticed
<kaelyn>that it would sometimes seem to stall for a few hours hours without new output from the guix command, but top showing continued activity. Most often that would occur while building ghc, and from what I can tell it has now built ghc 7.10.2, 8.0.2, 8.4.4, 8.6.5, 8.8.4, and 8.10.7 just from "guix system reconfigure --no-subtitues my-host-config.scm" (i.e. not trying for a full bootstrap). I'm curious about it as it seems, well, very
<kaelyn>inefficient. I should also mention that my system config does not (knowingly) include any Haskell packages.
<jpoiret>kaelyn: well, it has to be pulling ghc in somehow
<jpoiret>you could look at the packages in the system profile and see if any of them pulls it in
<vivien>singpolyma, that’s tempting, but I have 2 problems with that. First, tracking the latest commit on main/master needs to add an awkward "update package" commit that gets in the way, and second you can’t do a reset or rebase on the branch that the channel expects because guix will detect it as a downgrade. Plus, it’s hard to automate packages updates to always track the latest commit, because if you update the packaging code then you’re doin
<vivien>g a new commit, and thus the packaging code will always be 1 commit late wrt the actual code. If I have one branch for the code and one for the package, I can add a commit hook to automatically add an updating commit to the packaging branch with no impact on the main branch, so code and packages can always be in sync
<kaelyn>IIRC from when I saw ghc being built a few months ago, I think one or more system packages use pandoc for generating docs, but I'm not sure which. My question isn't so much about why ghc is being pulled in at all, but why 6 different versions are being pulled in / built.
<singpolyma>vivien: ah yes, I have my guix.scm get the current commit programmatically, I never commit an actual commit hash
<vivien>That’s a very clever way, it lets you bisect things too
<nckx>kaelyn: Building any Haskell package needs ‘ghc’ (8.10) which needs ghc-8.8 which needs ghc-8.6 which needs ghc-8.4 which needs ghc-8.0 which needs ghc-7 (which is build from ghc-bootstrap-7.8 binaries).
<vivien>nckx, I’m experimenting wildly in this parenthetical world. I’m not sure of anything, but if there’s a perfect way to hack packages and packaging simultaneously, then I’ll find it one day 😎
<nckx>They are temptingly similar, it's just the workflows that are currently very different (unless someone has a grand unified channel/shell workflow already — I didn't check out singpolyma's link yet).
<singpolyma>I don't make a channel, but I do bake my guix.scm in CI into the file we use to install in prod, so basically the same
<vivien>I often have bizarre workflows, so maybe if a perfect solution exists for me then it won’t be the same for you. All I know for now that if it exists, guix and guile are a big part of it.
<singpolyma>Also check the manifest.scm in that same repo for a way to get hacking around only stuff like linters in
<nckx>singpolyma: But you can't ‘guix install’ it or use it anywhere in the dependency graph, right? It's isolated in that sense?
<nckx>It's OK for the servery appy kind of ‘deployment’.
<singpolyma>I do in fact guix install it. For prod I serialize the baked version in CI and guix install that
<singpolyma>If you look at it you'll see I double escape my package def, then eval it in two stages. So the middle "baked" stage I can use display on and get an sexp for prod for a certain commit
<vivien>Compared to gitlab, guix CI/CD is lest tightly integrated. CD is a huge plus for guix, because it can do frequent unattended upgrades, and for CI we have cuirass, but it doesn’t prevent broken commits from entering the repository.
<jgart>Thank you! Working on guix docs together feels pretty good. I feel we learned a lot from each other and about people's mental models for GNU Guix concepts. I definitely had atleast > 5 TIL moments.
<jgart>It would definitely be more boring to work on guix docs alone. Atleast for me.
<jgart>civodul, I pasted the chat log and our notes from today above. I'll resend them to guix-devel.
<jgart>The meetup notes included a list of documentation tasks that people voted to work on. Today we chose adding documentation on documentation :)
<jgart>Gabor mentioned possibly contributing to the glossary and adding more Guix-specific terms.
<dcunit3d>the docs for guix/guile/gnu are really, really good. but as a noob, i still find myself getting confused quite a bit. i'm not sure that my input would be valuable, but i'm interested in hearing more
<jgart>I think there is also a lot of undocumented build/package helper functions that Gabor mentioned
<dcunit3d>things that would've helped me: i wish i had been using info-mode properly this whole time and guix-mode is very useful earlier on for a beginner. also, it was pretty tough trying to get guix to work in arch linux (e.g. managing multiple profiles without conflicts as a noob), but much easier for me to understand once i installed guix-system.
<dcunit3d>i have no idea how to make it any simpler than it is without watering down guix and imposing constraints
<char>jgart, wxwidgets is in inputs and native inputs for now just for good measure. The store location of wxwidgets (which includes wx/version.h) is in CMAKE_PREFIX_PATH.
<jgart>dcunit3d, You're input is very important. If you're free next month I hope you can join us.
<jgart>I'm also offering free mentoring to anyone on Guix packaging/development. Just contact me for more info and we can figure out a time to meet online. I might be able to do one or two Guix packaging mentorings a month total. Maybe more. Depends on my work schedule.
<char>jgart, it is also notable that if I build manually with guix shell --pure -D, it compiles just fine.
<dcunit3d>thanks jgart. something like that would help a lot :)
<jgart>florhizome[m] and I are working on packaging pantheon if you'd like to join us in those efforts
<jgart>ryanprior[m] contributed the first pantheon packages to Guix iirc
<jgart>I just use the elementaryOS wallpapers because they look nice with dwm ;)
<char>jgart, really nice. the gtk icons are not glitchy anymore which always bugged me.
<ryanprior[m]>lprndn did a lot of work as well that still isn't upstream yet
<roptat>one thing we talked about is the wiki on libreplanet. It's listed on the website under "help", but this wiki is not really designed to be used to get help, rather it's more organisational (at least at the moment, I see only stuff about fosdem, gsoc, outreachy, ...)
<phf-1>Would not the `(arguments '(#:tests? #f))' cause problems?
<char>phf-1, you only want to skip tests if there are no tests or there is some problem with the tests themselves. Skiping tests will not break guix though.
<phf-1>char: well, I know enough git to get by. Well, I just stick the package definitions in `(gnu packages python-xyz)', get the git patch files, send them to firstname.lastname@example.org and see what happens. Correct?
<char>phf-1, that is correct. It is also good to run ./pre-inst-env guix lint <package> on your packages to make sure they conform.
<bricewge>You can try to set the environment variable`COLUMNS=999`
<jgart>how do people do debugging with guile/guix? Do people use the guile debugger ever? :) If so what's your workflow? Only use guile debugger in emacs buffer? without emacs (or not a good idea because support is way less)?
<ngz>wow. Some package was bumped from 0.9.9.9 to 0.9.9.9.9. Someone is having fun with versioning.
<darosior>Hi, the download page states "the standalone Guix System can be installed on an i686, x86_64, ARMv7, or AArch64". However it only features iso for x86_64 and i686. Does someone know where i can find an iso for aarch64?
<Ribby>Alright everyone, I'm doing a sit-in to get this os installation going!
<Ribby>Otherwise, I will have to reflash the usb into a different brand. More so, more less.
<Ribby>I'm going to need some help because I can't tell if something is moving or stopped.
<Ribby>The latest error line informs me that libblkid.so.1 is missing. I hope that my usb retailer didn't insert some other code. Need a screenshot? I can screenshot the error message, but I need an uploader acceptable to the GNU community. Otherwise, I'll try my best in the most professional manner possible.