<lfam>mdevos: You'll be more likely to get an answer after the new year's weekend <nij>leoprikler: This is related to a several hours ago. - Hmm what I was hoping for is to recover my system on any machine without any possibilities of dependencies failing. Without managing emacs packages declaratively.. I wouldn't say it's fulfilled :S <Formbi>you can use a guix manifest and use-package in init.el <nij>use-package doesn't seem to be declarative.. yes? <nij>It pulls packages from an external repo that could have broken dependencies.. <Formbi>straight is purely declarative AFAIK <Formbi>use-package can use packages from guix <nij>Formbi: I'm looking into straight! <nij>Formbi: as for use-package do you mean the emacs packages that have been packaged as guix packages? <nij>Formbi: I'm not sure if I understand what the "declarativity" in straight.el. <nij>Does it guarantee reproducibility, for example? In Guix and Nix, reproducibility is guaranteed by calculating a hash for each built program. But it doesn't seem to be the case in straght.el.. <nij>It does, however, seem to provide finer grain control to which package to pull. <nij>But it does not seem to be as complete as what Guix or Nix can achieve. <ryanprior>straight.el claims to support reproducibility using version lockfiles nij <nij>ryanprior: Right, I'm aware of lockfiles, and it seems that most of the time it does do the job. <nij>And it does seem to be the best that we have now.. <ryanprior>Okay cool. If it doesn't do the job sometimes I'm sure they would appreciate bug reports! <ryanprior>I'm really good at writing bug reports and would be happy to help if that's something that intimidates you (or anybody else reading) <nij>ryanprior: I might be a little bit too theoretical before actually trying. Perhaps in emacs it's fine, as there are not too many packages that have the same name, same version, but different behavior. Things are different outside of emacs.. so maybe that's why nix and guix have to take care of that more carefully. <nij>I will report if I found something that's actually a problem! :D <ccao001[m]>Hi guix! If I'd like to say build icecast without curl support should I inherit from the existing package definition and then add the appropriate configure flag to ```#:configure-flags```? <lfam>ccao001[m]: Working from a git checkout like that is most useful if you plan on submitting your changes for inclusion in Guix <ccao001[m]>If I want to quickly just hack the icecast package on my own system and build my custom build of it <ccao001[m]>guix edit doesn't allow me to save my changes as it is read-only <lfam>For something like this, which sounds like a custom package for a special use case, I recommend making a custom repo and using it with either the GUIX_PACKAGE_PATH environment variable or a "Guix channel" <lfam>It's the part after "(define-module" <ccao001[m]>so if I decide to not make a repo and just put my custom package in a .scm file instead I should use GUIX_PACKAGE_PATH ? <lfam>The way I use my custom package repo with GUIX_PACKAGE_PATH is to store it at ~/pkgs, and do `export GUIX_PACKAGE_PATH=$HOME/pkgs` <lfam>After that, the guix command will make use of the packages it finds there <ccao001[m]>or do you have a bash function/alias to set it when needed? <lfam>It should go in ~/.bash_profile. The point being that it should go in the login shell initialization files for your shell <lfam>After you add it, you can do `bash --login` to simulate logging in again <lfam>It's the difference between login shells (invoked when logging in) and interactive shells (invoked every time you open a new shell) <lfam>Guix actually depends on the distinctions between them, especially for the `guix environment` command <lfam>If you look under "FILES" in `man bash` there is a very brief list of the files and what they do <ryanprior>bashrc is for both interactive and non-interactive shells <lfam>`guix environment` operates by launching a new shell with different environment variables. The file ~/.bashrc affects the environment of new shells. If your ~/.bashrc exports environment variables — especially ones related to guix — then `guix environment` may not work correctly <lfam>ryanprior is right, but the main distinction here is between login and non-login shells <ryanprior>if you run a bash script it'll source your bashrc <ryanprior>which I think is kinda bonkers but that's what it is <lfam>Basically, environment variables that should always be in effect should be exported while logging in, and they will propagate throughout the environment <ccao001[m]><ryanprior "if you run a bash script it'll s"> is this the same for all shells or just gnubash? <ryanprior>(what do y'all think about creating a pure functional shell scripting environment with nice I/O monads that's extensible in Guile) <lfam>For the other shell (zsh), there is ~/.zshrc and ~/.zprofile, and the same points stand <ccao001[m]><ryanprior "(what do y'all think about creat"> a fork of gash? <lfam>Not sure about fish or shells that are popular on other unixes <ryanprior>wait is that what gash is? I thought gash was supposed to run normal posix shell scripts <ccao001[m]>what is the best way to search across all logs at logs.guix.gnu.org? <lfam>It's been there for a while, but I think something is malfunctioning. At least, it doesn't return all the results that it should. <lfam>Google might work better atm ***wleslie is now known as solitaire-e-conf
***solitaire-e-conf is now known as wleslie
<rekado_>I manually restarted “goggles.scm index” on bayfront after removing /var/cache/logs.xapian. <rekado_>the service doesn’t work correctly for some reason <rekado_>a problem is that it’s not guaranteed that guile-xapian is available in the environment, which is, I think, why the cron job fails. <zamfofex>Hello, Guix! Has anyone ever asked for a Deno package? I tried installing it with Cargo, and the only really problem I ran into was needing to install curl for “rusty v8” to build correctly. (So I think that means a package would be easy to set up.) <jlicht>zamfofex: It depends: it seems that rusty v8 includes building the entire v8 engine from source (yay), but for guix to be able to do that, you need to state where those sources come from. <jlicht>so you might need to package those sources separately as well, and get rusty v8's build process to pick up on the fact that you already have copy of the sources for them to build. <PurpleSym>Where and how would I add test cases for the python-build-system? <civodul>rekado_: hi! the command from "sudo herd schedule mcron | grep index" seems to find Xapian <civodul>PurpleSym: so far there aren't test cases for build systems per se <civodul>perhaps what you could do is isolate the relevant functionality so you can write unit tests for it <civodul>just like we do (guix build gremlin) for instance <civodul>PurpleSym: oh nice, i see; there are tests that use the host store when it's available, perhaps you could do that here <civodul>(this new phase looks like a great idea) <rekado_>ISTR that there’s an old bug report about this <nixo_>(section: How to unpack waf) <nixo_>it includes a waflib folder full of python files <jlicht>has anybody used guix' plantuml package, literally ever? <jlicht>I'm getting "error in dlopen: #f: cannot open shared object file", for pretty much any version I can reach with the time machine and the current version of that package just the same <nixo_>jlicth: I think I did, and it worked <jlicht>nixo_: thanks, I'll have to dig a bit deeper then :/ <nixo_>jlicht: which command is failing? <zimoun`>piouf! a couple of days off and so much to read and unpack. Cool! :-) <alextee[m]>it looks like the app is trying to get a dejavu font: access("/gnu/store/7y3lvk3xf4im8n44337mc6y0ccysvfia-font-dejavu-2.37/share/fonts/.uuid", F_OK) = -1 ENOENT (No such file or directory) <alextee[m]>i can see the .ttf fonts in there but I think guix doesn't allow the app to create a .uuid file there <alextee[m]>and this is how im testing it: `LV2_PATH=/gnu/store/z2xjjfpaybyv1byal7nxrvqxd7b1hjqh-distrho-ports-2020-12-27/lib/lv2 jalv.gtk3 urn:juce:TalFilter2` (needs jalv and jack) <nixo_>jlicht: I was using svg and eps output (-tpng), both working. plantuml file fails for me too <nixo_>jlicht: png prints the error but the file is created.. <jlicht>nixo_: interesting; do you have a complete example of something that WorksForYou (tm)? <jlicht>ah nvm, I see it too. thank nixo_! <civodul>nixo_: oh indeed, i even participated in the discussion :-) <nixo_>now the number of packages using waf is 27, so it's still feasable to unbundle it <daemonspudguy>It's really bizarre that I could never get GuixSD running on my system. Stock Debian boots flawlessly, and that also is 100% deblobbed by default. <nixo_>daemonspudguy: Hi, in which way it does not run? What happens? <PurpleSym>Looking at PEP 517 the days of our python-build-system seem to be counted anyway… I’ve got issues with newer packages’ .eggs having no version number already. pytest@6 being one example. <daemonspudguy>Also, yes Debian is deblobbed by default. With Linux-libre's toolkit, no less. <zimoun``>I am failing to run make with 729f582a83; error: failed to load 'gnu/packages/shellutils.scm'. Do I miss something? <moesasji>system to use it in a way that the system uses the patched xkeyboard-config. Can someone give me a pointer? An example how one would exactly use a personal channel to replace a package like xkeyboard-config would be ideal... <daemonspudguy>No. But I said by default. You have to remember that Debian's nonfree and contrib repos aren't enabled at installation. You have to make a conscious decision to use them <leoprikler>Still, I'd claim that the comparison is somewhat off, given that Debian is not FSF-approved. That said, there is some potential for bugs unique to Guix, as others have e.g. reported issues, that didn't exist in Trisquel. <abcdw>Do someone knows, why goto definition doesn't work in geiser? (for some cases it work, but some does not) For example I'm at line 610 at gnu/services.scm on (activate-current-system) form, press M-. and get "Geiser: cannot edit symbol at point ..." <civodul>abcdw: that's because the module that provides activate-current-system is not in scope <civodul>in this case, that's because activate-current-system is actually called in a different stage <abcdw>civodul: Make perfect sense. But another example is line 582, activation-script function or line 571 service-type <abcdw>They seems to be outside of gexp. <civodul>abcdw: you also need to make sure to "use" the module you're visiting (the first time) with C-c . u <abcdw>civodul: Don't have such hotkey, what function does it call? <civodul>alternatively, you can compile the module with C-c C-k (from Geiser) <abcdw>civodul: Thank you very much! <abcdw>guix-geiser-eval: Sorry, the evaluation is aborted because it has taken too much time. <abcdw>Try to increase the value of ‘guix-geiser-connection-timeout’ <abcdw>variable if you have a slow machine, or please report if you <abcdw>think this command takes unreasonably long time to run. <leoprikler>is there a way of using version-major+minor or target-guile-effective version in configure? <candan>Hello everyone! I'm attempting to install jupyter notebooks but I'm running into some trouble. I <candan>I've `guix install jupyter guix-jupyter` but on running `jupyter notebook` I'm getting the error `pkg_resources.DistributionNotFound: The 'six' distribution was not found and is required by traitlets <leoprikler>candan: you probably need python3 for the correct python paths as well <candan>leoprikler: Thanks - I've got python 3.8.2 installed via guix. Also python-setuptools too (at this point I'm basically installing anything that sounds like it might work :D ) <leoprikler>fwiw rather than installing everything locally, you might give good ol' guix environment --ad-hoc a try. <leoprikler>once you've figured out a set of packages, that lets you actually run jupyter, you can install that <candan>New to guix so just reading up on --ad-hoc now... <abcdw>civodul: thank you, it seems mostly working! <civodul>candan: here's one that works for me: guix environment --ad-hoc jupyter python-notebook guix-jupyter -- jupyter notebook --no-browser <candan>leoprikler: boom got it! ` guix environment jupyter guix-jupyter -- jupyter notebook`. It takes quite a while to download stuff and load up - will it do so every time or can I maguixally load up this same environment next time? <leoprikler>candan: that actually pulls in all the dependencies of jupyter and guix-jupyter <candan>civodul: oops thanks! Didn't see your post. Ok so what are the advantages of your method over the one I used? <candan>leoprikler: isn't that what I want? <leoprikler>nope, you want the one that civodul posted, which pulls in just jupyter, python-notbook, guix-jupyter and their respective propagated inputs <abcdw>candan: it will do it once, next time it will be almost instant. <leoprikler>`guix environment` will always pull the freshest package, so it changes after `guix pull` <leoprikler>With `guix package` you will have to frequently run `guix package -u` or `guix upgrade` to keep it updated. <leoprikler>Also you can time-machine + environment to always get the same jupyter version <candan>guix is really incredible... it's so clearly the future. <abcdw>leoprikler: yep, cool note. The good idea is to lock the channels configuration with `guix describe -f channels > channels-lock` and do `guix time-machine -C -- environment ...' ***ggoes_ is now known as ggoes
<civodul>candan: you could "guix install" the exact same packages and it'd work <civodul>the advantage of "guix environment --ad-hoc" is that it creates the profile on the fly <civodul>thus ~/.guix-profile isn't cluttered <leoprikler>civodul: if I want to update guile-curl, but doing so requires harder code changes, should I first mail to guix-patches? <luis-felipe>cbaines: Hi, is it possible right now to request the Data Service for a list of all the packages that have been available in guix until the latest revision? <cbaines>luis-felipe, that sounds easy to do by querying the database, do you just want the names? <cbaines>note that data.guix.gnu.org only has data going back to the start of 2019, and there's not complete coverage of every revision <luis-felipe>cbaines: I'd like to get a JSON file if possible with the same information currently available for a package in the Guix website. <candan>Woops in a bid to tidy up my guix package list I --roll-back'd too many times. Is there a way to roll forward? <cbaines>note that this is for the latest revision only, not looking back through time <luis-felipe>cbaines: Yeah, that JSON wouldn't work for me. I'm looking to create package detail pages for the website that are future-proof. <cbaines>you can also adapt that URL to be for a specific revision <luis-felipe>cbaines: Thanks, I'll explore the data service a bit more. <rekado_>rolling back only switches the current generation; it does not remove any generation <rekado_>as long as you don’t run “guix package -d …” and “guix gc” you can always switch back <cbaines>luis-felipe, cool, let me know if there's some changes or additions that would be useful for you <candan>rekado_: `Missing required argument after `-S'` ? <rekado_>candan: you better check the help first <rekado_>-S takes an argument: the generation. <rekado_>but I can’t tell you what generation you’d like to switch to <candan>rekado_: ok thanks , sounds like I need to read through the docs properly. thanks! <rekado_>I suggest running “guix package --list-generations” <avalenn>What is the equivalent of "nix-instantiate" (create .drv without building) with guix? <rekado_>that shows you all generations; one of them will be marked as “(current)” <rekado_>candan: the number after “Generation” is what you need to give to “guix package -S” <rekado_>say you’re on generation 23, but you really want to be on 42, then you do “guix package -S 42” <candan>Oh. Ah yes I did see that in the intro video but forgot it - thought it referred to a hash <rekado_>candan: “--roll-back” is just a short-hand for the more generic “--switch-generation” <avalenn>and the equivalent of "nix show-derivation"? <candan>rekado_: oh makes sense... switch to the *lsat* generation <candan>is there any reason I wouldn't want to just use guix as a straight replacement for apt? Even ignoring the unique benefits of guix. Just as a package manager with more up to date packages than, say the debian repositories? <lfam>candan: Guix on other distros lacks setuid binaries. I find it easier to let Debian handle the system layer and use Guix for applications <lfam>Also, on Debian, services and packages are intertwined. So by installing a package from guix you may lose some functionality <lfam>I mean, installing the package won't make you lose anything. But trying to replace the Debian package with a Guix package <lfam>Like, on Debian you can do `apt install nginx && systemctl start nginx` and it works. There's a lot of setup that would be required after `guix install nginx`, and it would be hard to keep track of <lfam>It is really nice to use Guix on Debian, though <candan>I suppose if you did, say, install and run nginx from guix though, one benefit would be, eg config files all being stored in ~/guix-profile/etc/, which would make... i dunno, backups easier, assuming you follow symlinks? <candan>Not esaier but simpler... you only need to backup your home (symlinks including, again) <lfam>candan: I don't think that nginx config files would live in ~/.guix-profile/etc when installing nginx with guix <lfam>They would go wherever you put them, but guix wouldn't handle them <morgansmith>so I installed nix so that I could install signal-desktop, but the fonts don't work. Does anyone know how to get them working? <morgansmith>I tried that, but nix says I'm supposed to set the fonts.fonts setting instead. but I have no clue what that means. I found a font config snippet on the nix website and copied that into my config but now it tells me fonts.fonts is an unknown setting. I'm very very lost <moesasji>morgansmith you could also opt for the flatpak solution for things that are not yet available on guix <morgansmith>flatpak was giving me grief so I was trying to see if nix would give me less grief. Other than the font issue, they seem to be roughly the same amount of grief <morgansmith>does nix have multiple config files? I'm putting my stuff in the /etc/nic/nix.conf file which according to nix manual is the only configuration file but everyones configs online look pretty different to this file <jgart[m]>morgansmith: I would also ask in #nix:matrix.org to see how to set up fonts on a foreign distro <jgart[m]>There are people using nix on ubuntu, fedora, etc... <civodul>rekado_: do you think the picture language would be a good fit for a graph backend, as in (guix graph)? <jgart[m]>nm emacsomancer was is in the same dilemma <jgart[m]>you could try that to install SourceCodePro-Regular fonts for example <morgansmith>turns out I was using the wrong configuration file. also turns out they have 3 different manuals. I really don't like their documentation <jgart[m]>Yes, there is a manual for NixOS which is the distro itself, Nix the language, and Nixpkgs which are the source files for the package definitions, services, etc...The Nixpkgs manual shows guidelines for how to contribute to nixpkgs and how to do specific things with the source tree as needed (e.g. installing unfree packages, overlays, overriding, etc...) <morgansmith>I'm just upset because 2 of the 3 manuals have a preface letting you know of all the manuals. And I had to start with the manual that doesn't have that preface <apteryx>is the texlive importer universally broken? See: guix import texlive ec <leoprikler>well, surely you wouldn't care about nixos if you didn't come from any of the other two manuals <morgansmith>I'm very upset that the difference is literally 2 letters in the url. I literally cannot tell these manuals apart without taking an extra 20 seconds each time I switch to a tab <jgart[m]>I'd like to write a procedure called fetch-from-gitlab that takes four arguments gitlab-username, repo-name, rev, and sha256. Can this be easily embedded in the package record field? <leoprikler>wouldn't that simply be overfitting the git-fetch origin method? <jgart[m]>essentially i'd like to add my own procedure for pulling packages from gitlab <jgart[m]><leoprikler "wouldn't that simply be overfitt"> I think so <jgart[m]>I want to use fetch-from-gitlab in place of it <morgansmith>is the benifit of this to be able to specify users so you can play with forks? Like some kind of --with-gitlab-user=foo <leoprikler>I think you could simply make it a procedure, that returns an origin <leoprikler>I don't see "gitlab has this" as a valid reason for upstreaming it tho <jgart[m]>I just want to use it for my personal packages <jgart[m]>my own internal language for experimentation <jgart[m]>of course I'd make it public but I don't expect it to be accepted upstream <leoprikler>As I already pointed out, you could simply make it a procedure. <leoprikler>As long as it evaluated to an origin record, Guix will happily eat what you throw at it. <jgart[m]>I just meant extending the api. Not a full blown language <jgart[m]><leoprikler "As long as it evaluated to an or"> cool, now to just implement. I will try soon <jgart[m]>It reduces lines of code a bit. I'm just curious to be able to do this with guix <jgart[m]><leoprikler "wait a sec, lemme code that real"> that'd be great! can you share it here? <jgart[m]>you can have a fetch-from-gitlab, fetch-from-sourcehut, etc... or maybe there is a way to dispatch or something <morgansmith>reduces lines a bit? aren't you taking the url field from the git-fetch and splitting it into user and package name? Wouldn't that take more lines? <jgart[m]>It would take more lines to implement the procedure but it will take less lines when you are packaging a new piece of software <jgart[m]>the string-appending, etc... that needs to be done usually for a github/gitlab package would be abstracted away or handled by this new procedure <jgart[m]>lines 986 - 994 would be abstracted away by this new procedure with four arguments <morgansmith>if you could rough out the syntax for me I might be more convinced <morgansmith>I'm noticing we have a lot of lines taken up by (file-name (git-file-name name version)) whenever we do a git-fetch. That's not necessary right? <morgansmith>I just removed that line from a thing and it seems to still work fine <lfam_>morgansmith: It means the source code won't have a descriptive name <lfam_>Things will work but it's not ideal ***lfam_ is now known as lfam
<jgart[m]><lfam_ "morgansmith: It means the source"> What do you feel is lost? <jgart[m]>I see it as both ways having pros and cons <lfam>jgart[m]: The name will be something like "/gnu/store/a79yv1yw5l645d5vp255gqdn52vmb34d-git-checkout" <lfam>It's better to have the name, this is why the linter warns about it <morgansmith>lfam_: I literally see no difference in paths when you have that line vs no having that line. maybe I'm not testing it right but removing that line still results in /gnu/store/6zk2cccvzvlskq7yw5vkdmax7mkmwcmp-emacs-dimmer-0.4.2-checkout for me <jgart[m]>The former is more descriptive the latter is more terse/concise <lfam>It's likely that you already have the thing described by the hash in /gnu/store, so Guix does not try to create it again <morgansmith>I really don't think that's the case. could you humor me and try it for yourself? <jgart[m]>lfam, could you share the snippet of the implementation? <lfam>morgansmith: Delete the source checkout and try again <morgansmith> building /gnu/store/k754xhm5614k59irgpdqal395yrzz5am-emacs-flycheck-cpplint-0.1-1.1d8a090-checkout.drv... <morgansmith>and then I see all the git pull stuff. like I'm darn certain I'm doing this right <leoprikler>morgansmith: you mean the warning regarding "master" or what? <morgansmith>My repo is a little messy, so maybe I'm not doing it right, but it really looks like that line isn't doing anything. have you tried it yourself? <lfam>morgansmith: Yes, so many times <leoprikler>that's just git promoting branch names other than master for default <morgansmith>how do you clean out a checkout? I've just been switching to a new package each time :P <lfam>You delete it with `guix gc -D /gnu/store/...` <lfam>The source checkout will not be named descriptively <morgansmith>ok, it was because my guix was dirty. I did a rebuild and things magically changed so now I do see the correct results which you say. Sorry for wasting your time. I just didn't want to rebuild things :P <lfam>This behaviour (source doesn't get rebuilt unless the hash changes) can mask issues like incorrect URL <lfam>Every guix hacker learns about it in a similar way :) <lfam>`guix build foo --source --check` does work unless there are patches or origin snippets, in which case only the patching is re-done <morgansmith>oh shoot! it didn't spit out the normal warning of the guile not being compiled! <lfam>Another problem familiar to seasoned guix hackers <lfam>Now you are on your way :) <morgansmith>so how come in origin-actual-file-name (guix/packages.scm:324) we don't just throw a branch in there for git names when they aren't specified? <morgansmith>I was more kinda asking that because I didn't want to assume I was in the right place :P I still don't understand the package structure. It looks like that's what turns URI's into file paths but I'm still not 100% certain <leoprikler>well, assuming you are in the right place, that would trigger a world rebuild <morgansmith>I'm not sure what triggers world rebuilds, but wouldn't this only cause packages that currently have the file-name set to #f to be changed? <leoprikler>well, sure, but those are likely still large in number <lfam>If you make a change that rebuilds the world, you'll notice ;) <leoprikler>there's a way of iterating over all packages, but you are on your own for the rest <morgansmith>if I could iterate over all packages it'd be trivial to run a check on the value of origin-method and origin-file-name. How do I got about this iteration? <morgansmith>I got side tracked and wanted to see how many lines this change would actually allow us to remove and it seems the number is 3265 <morgansmith>this is only for git-fetch though. If we did it for more methods, the number would be higher <leoprikler>but I feel there are more than 3k packages using git-fetch <morgansmith>I was gunna give you the command but apparently my terminal history is messed up. one sec <morgansmith>find . -type f -name '*.scm' | xargs sed -i '/(file-name (git-file-name name version))/d' <morgansmith>but this is only important because I like numbers. the real benifit would be increased readability of package descriptions by having fewer trivial things in them ***nparafe is now known as antidoto
<morgansmith>ok, 71 package sources aren't origins. I'll need to look into that but I did a fold-packages correctly! I'm very proud of myself. I've literally never written a standalone guile file <rekado_>civodul: I don’t know. It’s just a few procedures that work on SVG. What do you envision? <morgansmith>also, how are you supposed to increment a variable in guile? I did (set! result (+ result 1)) but that felt gross <morgansmith>you guys and your fancy match stuff. maybe I should learn match... <morgansmith>anyways, that means that my change likely wouldn't cause a world rebuild, right? <cbaines>morgansmith, I'd switch when to if, if the condition is true, put (+ 1 result) and for the false case, put result <leoprikler>that's just for ensuring that I don't accidentally refresh packages from the dirty channel <leoprikler>okay, but apparently I don't get sources correct <morgansmith>gnu/packages/shellutils.scm:59 needs a base32 added. Could someone with commit access do that quick fix? Guix currently doesn't compile because of it <apteryx>rekado_: I've just sent some simple 'mitigation' for the TeX Live importer <morgansmith>it worked for me earlier today too actually... that commit was 8 hours ago. still, there should be a base32 right? <lfam>I don't know. Maybe it defaults to base32 <morgansmith>error: failed to load 'gnu/packages/shellutils.scm': <morgansmith>ice-9/eval.scm:293:34: Wrong type to apply: #<syntax-transformer base32> <apteryx>rekado_: hmm, I've left the pk's in... <cbaines>morgansmith, that's a Guile issue/side effect, at least my perception of that is Guile has messed up running the software <cbaines>The base32 syntax is good, because it performs compile time checking of the value, but it's apparently not strictly necessary to build the package <morgansmith>idk, I just want it to build so I can't test my other things. I've added the base32 myself. Still not sure exactly why it failed that time then <lfam>In what context does it fail? <apteryx>rekado_: it's a tragedy that the TUG Working Group on a TeX Directory Structure didn't choose the package name prefix. <apteryx>it would have made packaging trivial *leoprikler has super cow powers. <leoprikler>btw. we really need to do `guix moo` at some point <morgansmith>I'm only now realizing that to automate the creation of the file-name in an origin, the origin now has to know the package name. Something it does not know. I'm not really sure how to overcome that issue :/ <morgansmith>I went through all the trouble of asking if it was worth it far before I asked if it was possible... I feel like a fool <leoprikler>Well, that's the opposite end of "we kept questioning whether we can, but never questioned whether we should". <morgansmith>well, at least I learned a few guile things. There are worse ways to kill time <lfam>I think it's a good learning experience, even if it doesn't lead to patches <moesasji>in terms of learning experience: can anyone give me a hint on what the correct approach is the add a custom xkeyboard-config? It is clear to me how to create a variant, but not how to add it to the system-config. <morgansmith>I'm tempted to claim that the filename should be based off the git url and not the package name just so I could make a patch, but I don't think that'd go over well. It's in this odd inbetween where it should be seperate enough from a package to not require information from a package, but is used so closely with packages that we would like it to be named after them. Also if I did try to change the file-name, I think tha <morgansmith>moesasji: Did you read the manual section 10.2 ‘operating-system’ Reference? All you have to do is give the keyboard-layout field a value <moesasji>morgansmith: yes read that, but I want to add my own custom layout system-wide. Hence the desire to replace xkeyboard-config <morgansmith>huh, the manual doesn't have a link from the operating system reference page to the keyboard layout page. Maybe I'll have a patch today anyways <mdevos>Take a look at (gnu system keyboard), and (gnu services xorg). It seems keyboard layouts are referred to by name, so as it is now, a custom layout would be possible, I think. Unless you want to chose a different than default, but still standard keyboard layout. <moesasji>I have a patched xkeyboard-config....just need to figure out how I can replace the default version. The manual on variants points to channels, but isn't very clear how <mdevos>Changing between, say, qwerty and azerty would be simple, but switching the ‘t’ and ’b’ key but keeping everything the else the same seems complicated. But patches would be welcome I suppose :). <mdevos>moesasj: you can also do ./pre-inst-env guix system reconfigure etcetera, from your locally modified guix <mdevos>(I haven't tried that, but I see no reason why that wouldn't work) <moesasji>but doing that goes against having it embedded in my system config. <mdevos>moesasj: where in the source code did you modify exactly? <mdevos>If your modifications can be made generic (such that other users of Guix can specify their own custom layouts), then you can submit a patch to Guix upstream <mdevos>are you trying to modify the console layout, or the layouts available for Xorg? <moesasji>if you look at the guix source for keyboard layout you'll see that it uses the xkb source for both xorg and console <mdevos>If it's Xorg, then it could just be a matter of overriding the package field of the xorg service, with a patched xorg-server that used an alternative xkeyboard-config input <mdevos>you can use (package (inherit upstream-xorg) (inputs (code for replace the relevant input)) for that <mdevos>(Warning: I'm not familiar with the specifics of keyboard layouts in X. Maybe some other packages must be overriden as well) <moesasji>and for the base system you wouldn't have xorg <moesasji>I think the answer lies in using 'package-input-rewriting', but I don't see examples that make sense to me. <mdevos>moesasji: like any other package? (xorg-configuration (server your-customised-xorg-server)) <mdevos>and I don't understand what you mean by ‘and for the base system you wouldn't have xorg’ <mdevos>If you're trying to modify xkeyboard-config, that means there's a probably some GUI, so presumably you're running Xorg? Unless you work on the console only? <moesasji>if you look at the minimal sysconfig example you can still set the keyboard and that one doesn't have xorg installed. It uses the keymaps installed by xkeyboard-config to set the console layout <mdevos>Hmm, it seems you need to pass a custom xkeyboard-config argument to keyboard-layout->console-keymap <moesasji>that is why I went for using a modified source approach as that way my own layout would act the same as any other layout...but now I don't see how to replace the default package in a way I would do that when not using guix <mdevos>You can add an additional keyword argument #:keyboard-layout->console-keymap to raw-initrd in (gnu system linux-initrd) <mdevos>that will allow you to use your custom xkeyboard package I think <moesasji>the system will still need to 'know' about my custom layout in the first place <mdevos>you can add a custom initrd in (operating-system ...) definition <mdevos>Also modify base-initrd likewise, <mdevos>and set the (initrd ...) field to a procedure that will call base-initrd with your custom layout package <moesasji>mdevos: I think you focus an the wrong element. I need to get my layout to end up in the correct xkb folder so that the guix tools can use it in the same way as any other keyboard layout. <moesasji>I think my question is really how one overrides an existing package....that bit is not clear to me from that section in the manual <mdevos>???, isn't the keyboard layout set in the initrd? Then modifying the initrd to use your own keyboard layout package would do the trick no? Isn't that what you need? <efraim>cbaines: don't blame yourself, that was past cbaines <moesasji>you set the keyboard layout by setting those fields, but if you look at the keyboard.scm source you see that it uses the layouts that are placed in the xkb folder that xkeyboard-config populates <mdevos>Didn't you write a forked xkeyboard-config that includes your custom layout? Then teaching the relevant procedures to use your package variant instead of the upstream package, then these procedures will use the layouts in your package, no? <moesasji>indeed, but I don't see how to get my package variant to replace the default package (except by hacking it directly in guix source and that seems not the way to do it) <mdevos>Alternatively, if you don't mind modifying guix code, you could just override the origin in the xkeyboard-config package in (gnu package xorg), by changing the code? <mdevos>I think I have all I need to write the patches myself, I'll be back later <cbaines>sss2, you could try installing pidgin from before that commit was merged <moesasji>mdevos I was trying to avoid that approach as it must be possible to do it properly using a channel. Anyway thanks for the thinking and have fun writing patches! <cbaines>sss2, this might do the trick: guix time-machine --commit=2cb5ebf7a89b59e3e220b837202e4469e1db38c7 -- install pidgin <mdevos>some changes to guix are sometimes necessary, not all can be done for a channel. But if its something useful to everyone, then there's no reason to keep your code in a channel and not submit it upstream. <cbaines>sss2, feel free to open a bug about this as well, or I can if you'd like? <sss2>i think i should learn how to write packages for guix <sss2>i though one of reasons of guix esistence is avoiding such conflicts ... <sss2>looks like i got something wrong <rekado_>hmm, I’m annoyed by the fragility of ibus on Guix + Gnome <rekado_>every time I want to switch to an input method I don’t commonly use I does not work. <rekado_>even the usual workaround of deleting things in ~/.cache/ibus or ~/.config/ibus doesn’t help <rekado_>I removed and added again ibus-libpinyin in the Region & Language settings of Gnome <rekado_>but I can’t switch to it, nor can I configure it (I click on the settings button and it just times out) <apteryx>rekado_: until a better importer, the following produces the list of paths to pass to the simple-texlive-package procedure: sed -E -n 's|^.*texmf-dist(.*/jadetex/).*$|"\1"|p' $(guix build texlive-bin)/share/tlpkg/texlive.tlpdb | uniq :-) <apteryx>well, it lacks the non-directory entries such as the man pages <mbakke>apteryx: I haven't been following the chat lately, what is the context? *mbakke still needs to rebase their TeX Live 2020 work on top of the recent core-updates changes <lfam>Does anyone have advice on checking for cyclical module dependencies? <civodul>lfam: hi! there's what Mathieu suggests there <civodul>it could also be a cyclic package dependency (not module) <civodul>what does the Cuirass evaluation log say? <lfam>It's my first time poking around but the latest logs that I can find in /var/log/cuirass/evaluation are from Jan 1 <lfam>"/var/log/cuirass/evaluations" <cbaines>I was looking through the Guix Data Service log, as there's some error handling for parts of the process <cbaines>looks like there was an exception with computing the derivation for one of the system tests, as PostgreSQL 13 conflicts with 10 in a profile <cbaines>where it says: error: all-inferior-system-tests <cbaines>unfortunately it's not obvious to me at least which system test might be an issue <lfam>Probably one of these: `git grep postgresql-10 | grep gnu/tests` <cbaines>ah, zabbix is the one the Guix Data Service is looking at prior to the exception in the logs <cbaines>I'm still making .go files for staging... <lfam>I'd guess it's the operating-system in %zabbix-os <lfam>I guess we should adjusts all the tests, as a followup to the upgrade <cbaines>with any luck, fixing this system test will allow Cuirass to complete the evaluation <cbaines>I've implemented comparisons for system tests now in the Guix Data Service, and I'll sort out the page to allow easily doing it between branches, that might help spot that a system test is missing <lfam>I think it's the test suite of something <lfam>The "S"s represent skipped tests, IIUC <lfam>It's running. I just thought that it's absurd <lfam>It's the django test suite