<podiki[m]>continuing my cleaning out of my local packages <the_tubular>Anyone had success running emacs application framework on guix ? <KarlJoad>Does Guix system support an automatic backup option, like Guix home does? <char>I created a wxwidgets/include/wx directory with a symlink to the actual wxwidgets/include/wx-3.0.5/wx and added it to the appropriate environment variables. Same result. <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? ***dragestil_ is now known as dragestil
***yjftsjthsd32 is now known as yjftsjthsd3
***drakonis1 is now known as drakonis
<eonn>I restarted my computer, and now the module seems to be loading O.K. ***califax- is now known as califax
<jgart>singpolyma, re: don't require the modules in guixrus by their name <jgart>singpolyma, can you give an example of that? <jgart>not sure entirely what you mean by "by their name" <singpolyma>jgart: your script doesn't (use-modules (guixrus ...)) <mroh>eonn: Do you get an error message? Maybe it's worth a bug report. <jgart>so GUIX_PACKAGE_PATH=... takes care of that? <jgart>when I point it to guixrus checkout <jgart>singpolyma, on another topic, are you interested in spago for guix? <jgart>do you happen to know if spago requires bower to be in path? <jgart>singpolyma, I think I will work on packaging spago soon <jgart>I'll make a todo.sr.ht for it in case anybody wants to work on it together <jgart>logInfo "Generating a new Bower config using the package set versions.." <jgart>logInfo "Generated a valid Bower config using the package set" <jgart>I think I just finally answered my question: <jgart>runBowerInstall :: (HasLogFunc env, HasBower env) => RIO env () <jgart>logInfo "Running `bower install` so `pulp publish` can read resolved versions from it" <jgart>shell (bower <> " install --silent") empty >>= \case <jgart>anyways, I'll stop spamming haskell one liner snippets <eonn>mroh: I can't replicate it now, but I'm not one hundred percent sure why it happened. It might have had to do with how asdf indexes packages? I'm not keen on how the package management works. <jgart>eonn, what's your workflow for lisp with guix? <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? <AndrewYu>Thanks, I know, just wanna be assured. :D <vagrantc>which, for some bizarre reason, does not include FDL materials, which are so clearly not free, i don't know what to say. <vagrantc>(it's possible for FDL + exceptions to be free, e.g. guix documentation) <eonn>Are you talking about the Fee Documentation License? <vagrantc>yes, by default i cannot comprehend how anyone could consider it a free license ... <eonn>What makes you say that? <AndrewYu>Why do you consider the FDL to be nonfree? <vagrantc>invariant sections are part of the default license <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 <vagrantc>all of them have justifications, and maybe those are valid, i just don't understand how you can still call it a free license :) <zacchae[m]>eonn: I think you should make your own package definition that inherits the original st package, and just change the necessary part of that package def. <zacchae[m]>oh, I was scrolled up. looks like you figured it out <eonn>yep, I inherited st and for now I tarballed my modified source to point at <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) <zacchae[m]>Is there anyway to give the manifest file to "guix shell --manifest" as io instead of a file? <the_tubular>Also what are the policy for which package can be included in upstream guix ? <eonn>the_tubular: check the links I sent <the_tubular>Yeah, I've read it :P I'm just surprised I never heard about that before. <vagrantc>zacchae[m]: that sounds like a restriction on the type of changes you're able to make <jgart>does anybody know where I can find the code that generates these ids: /gnu/store/nckjv3ccwdi6096j478gvns43ssbls2p-python-wrapper-3.8.2/bin/python <jts>Do I need to do something in particular to make Guix install dependencies? <jgart>jts, `guix install foo-package` <jts>yeah it's not installing dependencies for some reason... <zacchae[m]><jgart> "does anybody know where I can..." <- when you say ids, do you mean nckjv3ccwdi...? <zacchae[m]>its a hash of the code after it builds (so you know that the contents of the folder is correct) <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 <jts>None of their dependencies are in my profile <zacchae[m]>I'm pretty sure if used on the same folder, it should give you the same hash. Someone do correct me if I'm wrong <zacchae[m]>jts: you might already have those dependencies downloaded for other things. are you able to run it? <jgart>zacchae[m], I think it might be in `nix/` <jts>no, it errors out for lack of dependencies <jgart>zacchae[m], libstore/store-api.cc <jgart>zacchae[m], the hash generating functions are in libutil/hash.cc I'm pretty sure now <jgart>There's a c++ function: `string printHash(const Hash & hash)` <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?) <PurpleSym>Note that the “hot cache” works on a profile level, i.e. if you pass a different manifest, it’ll be “cold” even though all packages are available. <jgart>PurpleSym, thanx for sharing the script <PurpleSym>You might want to look into JupyterHub as well. You could implement a custom spawner maybe. <jgart>I'll definitely check it out <jgart>PurpleSym, that went to a 404 <jgart>We should link up, maybe there are similar issues we are trying to solve <PurpleSym>Sure, you can always ping me here or in #guix-hpc:libera.chat. Most of the Guix-side issues are resolved for me, I think. <PurpleSym>Not sure why the github link is not working. You could also try psychnotebook.org <jgart>Is there a an example notebook running in the cloud on psychnotebook.org that I can see? <jgart>Does psychnotebook run the jupyter notebooks in a Guix container (guix shell -C -N ...)? <PurpleSym>You have to sign up to use it. You’ll basically get a UNIX account and then you can create “projects” and launch applications within. <jgart>How do you deal with the waiting for guix to build the container issue? <PurpleSym>jgart: If you bind to a port and don’t set a secret, isn’t it possible for every user to connect to other running instances? <jgart>Very much a basic implementation at the moment of running notebooks in the cloud <PurpleSym>What infrastructure are you running this on? <PurpleSym>If you say, “in the cloud”, do you use AWS/Azure/X or is it just a single server? <jgart>It's a virtual private server not associated with AWS, etc... <PurpleSym>Our biggest problem is memory, because every instance of `guix shell` consumes alot of RAM. <jgart>Yup, that has been a problem for me in the past too <jgart>I just sent a message to guix-devel detailing it <jgart>well, actually not the RAM issue but the caching of binaries and having the user wait <jgart>I guess you have solved it with the above <PurpleSym>I would call it “workaround”. The first start is still slow. <jgart>PurpleSym, how do you specify deps for a notebook? <jgart>Or, how does the user specify deps they need in relation to a notebook <jgart>Does the user add a manifest to the repo of the notebook? <PurpleSym>We don’t really have dependencies for a notebook. We organize everything in projects and every project has a `channels.scm`and `manifest.scm` to make them reproducible. <PurpleSym>And then a project can have any kind of executable code (Notebook, R script, …) <muradm>trying to use wine like guix environment --ad-hoc wine, but it attempts to build locally lots of packages, is it something wrong with me, or is it normal? <PurpleSym>And we have a package manager in the front-end. <jgart>PurpleSym, What is the user story for adding a new notebook? <jgart>Or, how does a user add a new notebook in the cloud from a repo of theirs containing the notebook? <jgart>I should probably try your system and see how it works :) <PurpleSym>jgart: Usually you would create a project, then start Jupyter Lab and create a new Notebook there. We don’t have a way to clone public repos yet, this is WIP. <PurpleSym>Our users usually have private scripts and data, not hosted on a public server. <PurpleSym>muradm: You can check with `guix weather wine` whether substitutes are available (if you enabled them). <jgart>Oh ok. Are you free to chat sometime over jitsi, etc and discuss the projects more? <jgart>BTW, I'm hosting a Guix Documentation meetup in a few hours over Big Blue Button. Next week we'll have a Packaging Meetup in case you're interested <PurpleSym>jgart: Yeah, sure, we can talk about that in more depth if you want. Do you just want to suggest date and time? <jgart>that's the guix-devel thread I had posted today <PurpleSym>I’m not really a documentation guy unfortunately xD <jgart>I'm tryng to get better at though <muradm>PurpleSym: thanks, but seems to be not very enlightening, guix env ... tells it will download something like 700-800mb of packages, guix weather wine says about 128mb.. <jgart>PurpleSym, Does 17:00 UTC work for you or earlier? <muradm>have to look to my old guix notes i gets.. <PurpleSym>muradm: Maybe it’s also downloading dependencies? Do you have a log? <GNUHacker>I need Qt 5.6+ Development tools, wich guix package I need? <PurpleSym>jgart: I’d prefer earlier. I have slots from 8–9 UTC or 12–14 UTC. <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 <muradm>i suppose that i should wander which one caused rebuild of so many dependencies <muradm>GNUHacker: qt-build-system gives those as far as i remember, from its dependencies you may look for packages needed, or may be just use qt-build-system? <muradm>another option take some basic qt package, and run guix environment <qt-package>, this will drop you into its build envrionment with tools available <jgart>PurpleSym, cool. See you then, exciting! I'm looking forward to it:) <lilyp>Since we are already sending out git commit notifications, would it hurt to scan the commit messages for stuff like "Fixes: <bug-link>" and then message bugnumber-done@debbugs.gnu.org? <the_tubular>Does that deserve a GNU buck, because freenode isn't "free" anymore ;) <nckx>It's free as in candy van. *nckx wonders why the Web site hasn't updated when that was scheduled for :38… <nckx>Have you been on ’Freenode’ recently? <nckx>I'm not sure it was a joke. <nckx>the_tubular: I don't recommend it. <nckx>Ah, at last, the page has updated. We're node-free. <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 <mbakke>'Output un-indented JSON on file descriptor 3 ("stddata") automatically if file descriptor 3 is present' -- what is this I dont even <mbakke>jpoiret: really, is "stddata" a thing now? <jpoiret>i don't think so no :) at least i hope not <mbakke>it's from the 'tree' changelog, the JSON output on fd3 breaks a 'password-store' test <mbakke>tree does not appear to use a VCS so I can't bisect it :( <jpoiret>why even would they do this without an option <jpoiret>when someone runs tree they don't really want any of that <florhizome[m]><GNUHacker> "lxqt-qtplugin dont work" <- You could look whether qt plugin packages set a search path. (QT_PLUGIN_PATH would be one that comes to mind) <florhizome[m]>There is also an open thread that the qt wayland plugin is often not found. Seems like a typical search path Problem to me, and we could try to find out which env vars qt looks after. <mbakke>the "stddata" stuff wouldn't be a problem if it still wrote its requested output on fd1 :P <nckx>The stddata thing is interesting but the semantics as implemented by tree are a bit weird. <mbakke>I'm patching it out for now, and will press the "send a nasty e-mail to the maintainer" button shortly :P <nckx>I'm going to send a nice e-mail to the maintainer urging them to ignore all the trolls. <xelxebar>Hey abrenon. Did you ever get that beamer presentation typsetting? <bricewge>I can't build my system from a guix checkout anymore, i get "git/bindings.scm:66:8: In procedure git_libgit2_init: Function not implemented" <abrenon>I've been working on the content, since, compiling it with Copenhagen <abrenon>I still have a bit more than one week so I might be able to triumph in the end <bricewge>I checked the last manual, rebuild the repo but I still have the issue <abrenon>I think in the worst case I'll simply put the theme in the same directory and compile with that juts to get the document ready <g_bor>abrenon: sorry, I am a bit out of context here. <abrenon>I just wish I could package the theme separately <g_bor>What are you trying to do and, what is missing? <bricewge>Also, just running guix from the repo i got the hint " Consider installing the `glibc-locales' package and defining `GUIX_LOCPATH', along these lines:" <abrenon>my advisor designed that beamer theme he wants me to use <abrenon>currently everything is copy-pasted accross each presentation we need to make, in overleaf <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 <bricewge>civodul: Thanks! I'll make sure *everything* is updated. <civodul>so, somehow debug-on-error is t in my minibuffer and i can't seem to change it <civodul>does that ring a bell to Emacs folks here? <g_bor>civodul: does that also happen if you start emacs with -q <g_bor>there was something a long ago resembling this with nxhtml <g_bor>that package was setting the variable on load <g_bor>removing elogind from the system makes the home test fail again <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? <mbakke>nckx: I think a40ac6271578ea061a8a07b2adbd6032a690ca70 is unnecessary since bd4f314bbac, no? <nckx>mbakke: I literally just saw your guix-commits mail. <civodul>g_bor: no, it happened after sending SIGUSR2 a bunch of times... to work around the long-line bug <nckx>mbakke: OK to revert a40ac62? <nckx>Are there other packages affected? <nckx>They are somewhat randomised. <mbakke>I've built './pre-inst-env guix build --fallback --keep-going --no-grafts $(./pre-inst-env guix refresh -l tree | cut -d: -f2 )', all fine <nckx>Never future, though, I thought that might break someone somewhere. <nckx>mbakke: I worried there might be a use somewhere I was unaware of, perhaps by some suckloss file manager, I dunno (I maintain that parsing unicode trees is a life decision to reconsider). <nckx>mbakke: It's far too late to be useful, but still, having a literal public log of my hobby hours bothered me. <civodul>nckx: i find it problematic too but couldn't think of a meaningful way to address it <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. *nckx as if there isn't a permanent record of 7 years of commits already. <civodul>but then there's the push time and OpenPGP signature time... <nckx>Most things I push to aren't signed, but good point, I forgot about that. <Noisytoot>tcc works fine if I build it without tests, but fails to build with tests <Noisytoot>Maybe tests should just be disabled in the package? <nckx>If it works fine why do the tests fail? :o) <nckx>The test failure is a segfault. In tcc. <nckx>‘Partially works’ is correct. <nckx>I'm not claiming there aren't Guix packages that don't segfault, in the wild, on valid input, today, no sirree. But disabling tests suites to allow it is a few bridges to the right of that one. <nckx>Also whytf does it segfault grmbl grmbl. <lilyp>Oh, I agree, at the very least it should be an issue known upstream <nckx>Which I'm not finding so far(?). <nckx>Unrelated: ‘failed to parse FAKETIME timestamp: Success’ \o/ Put it in the initrd. <lilyp>Noisytoot: we need answers 🙃️ <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>I think I could achieve it with a clever use of local-file, but then I wouldn’t be able to deploy it on the server. <nckx>vivien: Nice! I like the idea. <kaelyn>(oh joy. After 2082 min of clock time, that laptop update sans substitutes failed building rust because it ran out of disk space... *facepalm*) <vivien>Also the packaging code in its separate branch can scale to other packaging platforms, not that I would enjoy writing deb packages but still I could create a "debian" branch to do that. <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). <kaelyn>ah, an incremental-bootstrap chain. Thanks, nckx! <vivien>Maybe I could have both: a branch/channel to define the code, and a guix.scm that inherits the package and overrides version and commit <nckx>Unless there's a bug (and IIRC there was just that, at least a while ago) the later GHCs won't refer to their build GHC, but if you build from source, there's no way to avoid building them all. <nckx>kaelyn: I wish I'd scripted that answer, but alas : <nckx>vivien: I don't see the overlap between channels & guix shell anyway. One's for packaging, the other's for hacking around. <nckx>Maybe that could change… <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>To install hacked uncommitted version guix install it --with-source=$PWD <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. <vivien>However, git hooks work great with guix too <g_bor>I have made some progrss on the failing git-home test on systems without elogind. <g_bor>I really goes like that /run/user/xxxx is needed to make the test pass <jgart>We just finished the Guix Documentation Meetup and here are our shared notes from today: <jgart>[PATCH] doc: Document the documentation process. *vagrantc is probably a bit late to the party <ngz>jgart: It looks good. Nitpicks: markdown -> Markdown, org-mode -> Org, @code{[DOCUMENTATION]} -> @samp{[DOCUMENTATION]}, @command{make ...} -> @samp{make ...} <jgart>ngz, can I add you to the co-authors? <jgart>if so, just share how you want me to attribute you <ngz>Not for this kind of change :) I didn't author anything. <jgart>I'll reshare the above to guix-devel <jonsger>but I get an error which I don't understand: error: failed to load 'gnu/packages/icu4c.scm': ice-9/eval.scm:293:34: In procedure bytevector-u8-ref: Argument 2 out of range: 31 <jonsger>is this because the inherited package has a higher version then it's "origin"? <roptat>jonsger, sounds like an issue with the source's hash <jgart>What are the situations usually in which `(string-map (lambda (c) (if (char=? c #\.) #\_ c)) version)` is in needed in a package? <jgart>I've usually used fixed uris <jgart>but I see other guix packages that are using that lambda to decide between two options <roptat>it's useful when all versions follow the same structure <roptat>it's like using (string-append "foo-" version ".tar.gz"), but the file name contains 91_0 instead of 91.0 for instance <jonsger>roptat: ah thanks, that was it. 31 instead of 32 chars for the hash :) <jgart>but in this case with the lambda a version can follow one of two possibilities? <jonsger>jgart: didn't invented it. Just copied it from the other definitions in that file <roptat>string-map goes through the characteurs of the version and applies the lambda <jgart>jonsger, yup I grepped it just now and saw other packages are using it <jonsger>I tried to simplify via git-fetch, but it became not simpler :( <roptat>I didn't know about that actually, but I'll use that now <roptat>I used to use (string-join (string-split version #\.) "_") <roptat>don't know which is more readable <jgart>I think the one jonsger showed is more readable to me but yours is not bad either. Maybe I just have to get used to it... <jgart>not sure at the moment. ah both are clear he ;) <jgart>convoluted hello world program: <jgart>(string-join (string-split "hello.world" #\.) " ") <vivien>I wish guix shell could recognize a file named something like channels.scm, and run guix time-machine -C channels.scm -- shell -f guix.scm <SeerLite[m]>Was just thinking of something similar! Felt weird that it auto-reads manifest.scm and shell.scm but nothing for channels <jgart>Yup, that would be a very good feature to add <jgart>I mentioned channel --news the other day also: <jgart>I'd like to see news for all Guix Channels <jgart>If a package gets added or upgraded I want to know which channel it came from <jgart>I'm subscribed to a few channels <jgart>But, that might not be a trivial fix I'm told. I have to study it more <jgart>Are hiragana characters ok in commit message names or is romaji preferred? Or doesn't matter? <char> Hello. Could someone who knows cmake help me. Cmake reports Wxwidgets wx/version.h not found in <CMAKE_PREFIX_PATH>/include/wx-3.0, but wx/version.h is in there. <jgart>char, what package are you working on? <char>jgart, i'm trying to package visualboyadvance-m wxwidgets is a dependency <jgart>do you have wxwidgets in your inputs? <ngz>jgart: you sent a v2 for the documentation patch, but it looks like the same as the v1. Am I missing something? <jgart>might take a moment to arrive <civodul>jgart, roptat: congrats on the doc meetup! <jgart>civodul, thank you! It went well. I think we were productive today :) <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>and the source code, of course <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>you probably needed the development inputs to be available in the environment <jgart>char, sounds like that resolved it for you? <char>jgart, well the build fails on guix build <jgart>char, if so, try building in a container see if that helps: `guix shell --container -N coreutils -D guix --share=/var/guix/` <civodul>jgart: documentation on documentation sounds good :-) <civodul>actually there's already a "Documentation" section, but prolly not what you had in mind <jgart>civodul, I think roptat pointed that out in the meetup but then said this new section would be fine. <roptat>yeah, the Documentation section is about how to use the documentation of packages provided by guix <ytc>which window manager/desktop environment are you guys using with your current guix system? :) <roptat>what we added is documentation about how to contribute to guix's own documentation <char>ytc, gnome 40 with vertical-overview <jgart>char, how's gnome40 on Guix System? <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, ...) <char>and guestures with wayland work perfectly. <jgart>ryanprior[m], can you link that issue? <roptat>is the intent to make it more "helpful", or keep it as is? if the latter, I think we should link to it from a different location <jgart>roptat, I don't mind sending a patch for that if we know what we want to do <roptat>the thing is I don't know what we want to do <jgart>sure, we can wait till someone let's us know how to proceed <jgart>unless we should ping someone? <roptat>yeah, a bug sounds fine, it should be actionnable though <roptat>so propose possible solutions, and then send a patch once we know what people think <jgart>roptat, do you happen to know how to build the website ;) <char>jgart, any other ideas? the container build did not change anything <roptat>jgart, RTFR (read the friendly readme) ;) <jgart>char, can you share a paste? <jgart>roptat, haha ok, will actually do that now <roptat>the readme has the exact commands you need to run to test locally <roptat>essentially "hant build" and "haunt serve" in the right environment <roptat>alternatively "guix build .guix.scm" to build the full website (takes a lot of time) <jgart>oh we should add a manifest.scm <roptat>that's what the readme tells you to do <jgart>i have to get better at rtfr <roptat>guix shell -m manifest.scm and stuff <jgart>or read the friendly ls standard output <jgart>`guix shell` by itself should probably do now <roptat>the readme has some more options to set environment variables though <jgart>echo /home/guixer/guix-artwork/website >> /home/guixer/.config/guix/shell-authorized-directories <jgart>is any build-system dependent on the respective importer? <roptat>no, the build-system is always independent from the importers <char>phf-1, you need to send the git patch files to guix-patches@gnu.org. <civodul>roptat: yes, that's what i understood; documentation on how to contribute documentation is much welcome <mroh>char: Maybe try commenting out that -DwxWidgets_DIR line. cmake should find them via pkg-config and/org wxconfig. <char>mroh, I forgot that was in there. I added it to try to fix this issue and it makes no difference saddly. <phf-1>char: is there some kind of tutorial for a complete beginner to do ? <char>phf-1, do you know how git works? <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 guix-patches@gnu.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. <char>phf-1, also the commit message has particular format, just look at other people's commits and copy. also you can add a copywrite line for yourself <bricewge>Does someone know why `file-system-options` is a string instead of an alist? <bricewge>I just read the manual about `file-system-options->alist` but I can't find the explanation on why it isn't an alist. <jgart>is there a way that I can expand the ... at the end of this backtrace? <jgart>I would like to see the other stuff that the backtrace truncated from the printed object <jgart>I mean the `...` in each printed object <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>I'm trying to update qview to 5.0, but I'm encountering a build error "Permission denied". Current package definition is at <https://paste.debian.net/1227250/> if anyone wants to have a look. <jgart>bricewge, much better now :) <jgart>This is code by roptat from 2019 <jgart>after trying: `guix build -L . php-doctrine-instantiator` <jgart>in the channel repo root dir <SeerLite[m]>Hi, is the (non-root) guix command updated immediately with guix pull? Or is it after guix upgrade? <jgart>any help is much appreciated <ngz>SeerLite[m]: guix pull updates the command. <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. <Ribby>That's about it. It's for some legacy boot mode, or at least the bootloader stated as is. <Ribby>I'm pretty sure that my usb is for 64 bit <Ribby>Or at least what the retailer stated. <Ribby>The 64 bit instructions mention something about UEFI boot menu <Ribby>I just read about the libreboot bootloader so that's interesting. <vagrantc>Ribby: based on the very hard to read screenshots you posted, you seem to be very much past UEFI bootloader stages of the boot process <vagrantc>Ribby: i maybe missed some context, but i'm not sure what you're trying to do <Ribby>I just started on UEFI boot mode, it says this. <Ribby>"error: no suitable video mode found" <Ribby>Well, I'm trying to install the guix OS on the computer. I haven't tried live boot yet (was not aware of such a thing). <Ribby>For Linux brand, it is working (the computer I'm using now. ubuntu usb have a pendrive linux service, which.probably added in support files anyways. <Ribby>Maybe the bootloaders are the problem for the guix OS installation. Maybe I don't have a libreboot for my guix usb. <vagrantc>it looks like your bootloader is working, you've loaded a kernel and initrd and booted to it, but it does not seem able to find your rootfs <Ribby>Yes, that seems to be the problem. Something is missing. <jgart>I guess I accidentally did the right thing <roptat>I'll think about that, see you later :) <Ribby>vagrantc, do you happened to know what to do on such situations? Is the usb broken in some sense, or there's a way to update a (hot)fix? <vagrantc>Ribby: i'm not sure what you mean about usb ... is your rootfs on usb? are you trying to boot the installer from usb? <jgart>sneek: later tell raghavgururajan Do you want to still write a blog post on bitmask together? <Ribby>Yes, I am trying to boot the installer from usb. <darosior>Re the aarch64 iso of Guix SD, i figured i had to use "guix system image" to build an image for my rockpro64 (am i mistaken?). Does anyone know which image should be prefered? <jgart>does anyone know where I can read sneek's source code at? 
