<fishinthecalcula>@ss2 so i should just herd stop guix-daemon and manually start another instance? <pashencija[m]><roptat> "I think you're not using..." <- It's not, but I think I do not need them as I'm going to move to a guix fork once I get guix running. I need to be able to build anything myself anyway <acebulf>Nice! I'm starting out from scratch today. The entire concept of a lisp-configurable operating system is new to me, but I'm liking it so far <acebulf>In fact, I have like 1 month of lisp experience <brettgilio>I have been around Lisps (and Guix) for 3ish years now. <acebulf>I think I have to master it soon, because otherwise I will find myself unemployed :S Our part of the codebase is entirely SBCL, and everyone uses emacs as the editor for obvious reasons <acebulf>So I find myself in an unfamiliar land, which is both exciting and humbling <acebulf>Anyway, I'm trying to configure the Awesome WM, but it's not letting me edit the file. So far, I think that the OS is read-only mounting that part of the filesystem, and so I'm thinking I should be looking at where this is loaded from, but with no luck so far. Does anyone have some resources to throw my way that might help? <acebulf>Did the koans to get myself started with the syntax, which really is trivial to learn. I'm now going through two books, SICP (wizard book) and the French version of Lisp in Small Pieces <acebulf>Both do deep dives from two entirely different perspectives <acebulf>We're still in stealth mode, so while I can't give too many details, it's a company that builds alternative types of processors. (i.e. higher performance through different architecture) We use CL to build the firmware and kernel that runs on those machines <acebulf>I was intending to learn OCaml before landing my current gig, but things got sidetracked with having to move and whatnot. Still in the plans, but with less priority <brettgilio>I have since left professional programming entirely 😎 <acebulf>At university level or like high school? <brettgilio>I'm working on building an after-school program for programming in Racket <acebulf>Sweet! I'm technically a Physicist, and my love of science was spurred by my HS physics teacher. This would have fallen into my alley at that age <acebulf>Sounds super fun. I've heard good things about Racket <brettgilio>I figured if I ever wanted to return to the programming industry, it would be easy and feasible. Teaching does not pay well, and is quite stressful, but it works extremely well for my wife, my kid, and I's current situation. We get summers off together, all the same holidays, I know how to not take work home and still be effective, and the <brettgilio>Especially if I were to join like an educational software company. I would have a double whammy of being a teacher and a programmer. <acebulf>I feel like that kind of double-qualification double-whammy jobs are becoming more and more of a thing <Rampoina>what does guix offer for modifying the source of the packages? are there any tools that help with that? <Rampoina>I mean the sourcecode of the programs, not the packages themselves <brettgilio>My original goal was to get into compiler construction, but I resigned that would probably never happen for me <acebulf>Grad school is hell, but for some reason it's a hell that I miss sometimes <brettgilio>I got my bachelors in biophysics and math, and my masters in education <brettgilio>the education masters was easier than anything I did in my undergrad <acebulf>That sounds about right, the last two years of undergrad for my physics degree was rough. Then the grad school happened and I was working 60hour weeks. It's a lifestyle at that point, everything else gets neglected. <acebulf>At least, that's my experience with it. YMMV <Rampoina>brettgilio: do you mind giving an example of what those do? searching G-expressions in the manual leaves me just as clueless and there doesn't seem to be anything regarding patches. <Rampoina>Let's say I notice a bug in a program that I have installed, I want to check the source code, modify it, test it and install the modifications to my system (without involving upstream) <brettgilio>and you can invoke those in your package definitio <Rampoina>hmm, ok. so no tools that help with that really then <brettgilio>Side note, it is weird that Emacs 28.1 is not packaged, not even in emacs-next <acebulf>I agree, that was also kind of weirding me out <Rampoina>I was just wondering what those kinds of tools like guix (which are source based) do to help users actually modify the source code of their programs. <Rampoina>but it doesn't sound it does anything extra besides the typical workflow <Rampoina>in my opinion anything that actually encourages users to read and modify the code of their existing programs (and facilitates that process) is great <Rampoina>at the very least I imagine guix gives you an easy way to get a build environment for package X right? <acebulf>Yes, that I can testify to. It's also fairly promising for large deployments where you want machines to get the same behavior but don't want to use docker <brettgilio>acebulf For a community basically built around emacs, you'd think itd be there by now <acebulf>also yes, I don't know why emacs isn't there, there must be something that isn't working <Rampoina>what I envision is something like `guix edit-source package` which launches into a configured environment for that package and leaves you in the source directory, when you finish with your changes you'd do `guix apply-source` and installs your modifications <brettgilio>Rampoina have you proposed this in the email threads? <Rampoina>brettgilio: I haven't, I don't even use guix (yet) <warpedliver>you can have a guix.scm with a manifest for the IDE and use that <Rampoina>I assume they mean using --with-source pointing to a local clone <Rampoina>that sounds good, so it almost does what I was saying above <Rampoina>you need the additional step of figuring out where the source of the package is <warpedliver>ok, so I'm almost there to run a binary in a 'guix shell' container with all it's dependencies. The only thing that is missing is the sound. Dependencies are fine tho, if I elfpatch the binary with the guix profile with all the dependencies the app works just fine. ¿Maybe am I missing something to expose? <florhizome[m]><ta180m> "What's the current status of KDE..." <- Well first of all all things KDE will need an upgrade which is a bigger project. You are right that there aren’t that many packages missing for a kde–de though. <florhizome[m]>You probably want to start with an issue on the ml to coordinate things and gain people that help. <ta180m>florhizome: Thanks for the suggestion, I'll task about this on the mailing list. <warpedliver>ok, so; in guix shell, you can --share=${XDG_RUNTIME_DIR} --preserve='^XDG_RUNTIME_DIR$' and enjoy pulseaudio conection with the contenerized app. Don't know what exploits that opens, but I think it's good. <jpoiret>warpedliver: you could share only pa's socket <bdju>does anyone have experience with improving performance with intel integrated graphics and video playback in mpv (on guix system)? it seems I'm getting worse performance than some people on older/weaker hardware are, so something must be wrong on the software side <vats>Hello. I'm trying to rebuild my manifest, but somehow the derivation and store path for telegram-desktop is different for my setup than that on the substitute server. And the local build of that package is failing. How can I debug this situation? Do I start by debugging the failing build? Or is there any hope I can make my manifest use the derivation which successfully builds on the substitute server? <roptat>vats, to get the derivation that built on the substitute server, you would have to figure out which version of guix that was <bdju>you could remove it from your manifest, apply everything else, then install telegram-desktop imperatively afterward and also specify a specific version/commit that works instead of what it's defaulting to. that's what I'd probably do anyway. not sure how to find out why it's actually failing <roptat>and then you can either switch to that version or use an inferior <roptat>you'd have to look at the build logs to figure out why it's failing on your side <roptat>guix should tell you where the build logs are <vats>bdju: I'd need to install imperetively every time I rebuild the manifest, right? <bdju>could do it as one line with a little && there and rerun from your shell history each time <bdju>I do something like that to install a newer pfetch than the repo has <roptat>you can also use package transformation options inside your manifest <roptat>(although that's still dark magic for me, but I think there are one or two examples in the manual) <vats>I have used transformation options in the past, but I'd need to figure out the dependency that is causing the change. To find out exactly which package to transform. <vats>I think installing imperatively might be the only option here short of debugging the failing build. <roptat>mh, fwiw I can get a substitute from the latest guix commit <roptat>have you run guix pull recently? <vats>But oh, I don't think installing imperatively would install it. <vats>I'm on the latest commit. <roptat>what does "guix describe" tell you? <vats>c026db3f469d79e92155e7cb883830ccafc4206d <roptat>ok, looks like that's the tip of master <roptat>I get a substitute from that commit <vats>I also have telegram-desktop working in my current profile. I could get that commit too if that can help? <roptat>does guix tell you it'll build anything if you try "guix build telegram-desktop --no-grafts -n"? <vats>roptat: Do you think any of the channels could be responsible for the different hash/store path? <roptat>oh, if a channel defines telegram-desktop, that might be where it gets it from <roptat>how about "guix show telegram-desktop"? <vats>roptat: The location of package definition it provides is gnu/packages/telegram.scm:270:2 <vats>But maybe it is some dependency? <roptat>(because of the way guile modules work, dependencies are guile variables that explicitely come from a given module, in the case of gnu/packages/... it's always a module from guix itself) <roptat>so, does "guix build telegram-desktop --no-grafts -n" tell you it'll download a substitute? <vats>Well, it's showing me a different store path now which is available on the substitute server, apparently. <vats>roptat: --no-grafts made all the difference. <roptat>well, when you build from the manifest, it'll graft, but first it'll try to build/download the ungrafted version <vats>roptat: No. Building the manifest without --no-grafts still says it will build the failing version. <roptat>unless it's failing to build the graft? <vats>I don't know how to check that. <vats>But building it with --no-grafts seems to work. <roptat>what's the log of the failing build? <vats>roptat: I'd have to build it to get that. That could take some time. <roptat>oh, could you share the content of the derivation? (the .drv file) <roptat>ok, I don't understand, it's indeed a different package <roptat>do you have more channels or inferiors in your manifest? <vats>Yes, I have more channels. <roptat>in the manifest, or just with guix? <vats>In ~/.config/guix/channels.scm <vats>I don't have inferiors though. <roptat>ok, then I really don't understand how your manifest gets a different package with grafts, but gets the right one without grafts <vats>roptat: I see. Thanks for your help though. <roptat>vats, oh with grafts I also build it for some reason, instead of getting a substitute <PurpleSym>Question for the Guile hackers: Can I somehow use `apply` an `if` like so `(apply if (list #t 1 2))` (which apparently does not work). <roptat>no, because if is not a procedure <roptat>but you can apply a procedure that wraps the if, probably: `(apply (lambda (b t f) (if b t f)) (list #t 1 2))` <PurpleSym>True, that could work, roptat! I’m trying to modify the cabal lalr(1) parser to support elif statements, but – as far as I understand – it should be left-recursive, which makes it difficult to build a syntax tree. So I get a list of `(b t)`, then have to append `f` and run somehow apply the `if`. <roptat>you could match too: (match `((b t) f) (((b t) f) (if b t f))) <PurpleSym>That actually looks nicer roptat. But looking at `eval-cabal` it seems I need an sexpression in the form of ('if b t f). I guess I have to think that over again. ***caleb__ is now known as KE0VVT
<f1refly>looking at powertop, pulseaudio consumes more energy than my display at 50% brightness and the most power of any process in idle <f1refly>is this inevitable or is there something I can do about it? I tried setting avoid-resampling = true in the pulseaudio server config, but it seemingly didn't have any effect <oriansj>you can just disable pulseaudio entirely <f1refly>i think i'll try getting pipewire to work <AIM[m]><oriansj> "you can just disable pulseaudio..." <- Tell me when we get pipewire service through shepherd <AIM[m]>Current one is manually enabling it through xinitrc or something aye *roptat is about to send 54 ocaml package updates <z4kz>are there any cool use cases being used for guix that are non-desktop use cases? <z4kz>(I hope that makes sense) <z4kz>I'm just curious to see what people are using guix for other than for a desktop system <z4kz>I'm also curious to see how the features of guix help with that <roptat>I use guix on my servers, self hosting email, my website, ... <z4kz>how do you self host email? <z4kz>I'd think that would be pretty difficult to do. <z4kz>unless you mean an email mailing list? <jpoiret>sneek, later tell z4kz: the build farm (berlin) uses guix iirc <roptat>vats, fwiw, I managed to build telegram-desktop anyway, even if it didn't come from a substitute <lilyp>What's the problem with telegram-desktop? Building the existing package or updating it? <AIM[m]><roptat> "I use guix on my servers, self..." <- HPC as well <f1refly>how can i get the hash of a git repository at a specific commit? guix download only works on single files, I couldn't find the command to tell guix to check out repository x to the store :/ <unmatched-paren>f1refly: i wrote a script to hash a git repo, but it's written in fish shell... <unmatched-paren>first argument is the repo, second is the commit; default commit is master <f1refly>I'll adapt it for zsh and steal it for my rc if thats fine :) <singpolyma>f1refly: git clone, git checkout the commit, then guix hash -rx . <unmatched-paren>f1refly: yeah, i just quickly added that license notice right now :) <f1refly>If you're interested in moving it out of the shell <f1refly>how can I use a local git repository with git-reference? I tried (url "file:///absolute/path/repo.git") but when running guix reconfigure it tells me that it doesn't appear to be a git repository. is using file repositories not supported? <f1refly>yes it is and I didn't include .git in the real file line <roptat>if you want to refer to the latest commit, you can use git-checkout <attila_lendvai>f1refly, use a git-checkout object in place of the entire origin object <roptat>(origin (git-checkout (url (diname (current-filename))))) <karrq>Hello, I'm having an issue updating my guix on foreign distro. I haven't `guix pull`ed in a while... I tried a couple of times but it seems to always fail with the same error (when handling substitutes) ... In procedure: load-thunk-from-file: Invalid argument <attila_lendvai>karrq, i'm not very well informed in this, but i think it's something like a bootstrapping issue. you need to pull first up until a release, i.e. get a newer guix binary, and then again pull up until the next release, etc. not sure how, though. <attila_lendvai>karrq, maybe try something like: guix pull --commit=v1.2.3 to a tag that is next to your version *roptat is now updating translations <karrq>how do I check my version again ? :s <podiki[m]>question on something like a "source only package": I'm updating the AMD OpenCL rocm stuff, and one package will build but warns it is not meant to be built standalone and has no "make install" anymore <podiki[m]>the source is needed by other packages, should this package just be one that copies it source tree and that's it? *roptat pushed translation updates *roptat was sad to discover we already have the latest version of maven <civodul>sad as in, you won't have to update it yourself? :-) <civodul>that's a good problem to have though <roptat>I did a lot of ocaml updates, so I checked maven purely by reflex <civodul>podiki[m]: there's quite a few packages for C++ header-only libraries, i think that's ok <civodul>there are some cases where we provide, say, (package-source eigen) as an input <roptat>guix refresh -t opam still lists a few packages, but either it's not a real update (1.1 -> 1.1-1) or some dependents break <vagrantc>is guile-git in guix using libgit2 1.3.x ? *vagrantc keeps pushing and pulling patches between guix and debian <singpolyma>If only there was some kind of distributed tool for managing revisions to software 🤔 <GrigoryShepelev[>Want to experiment with guix api: wrote my own little build-system and own package, just to practice. <GrigoryShepelev[>Question: what's the optimal way to test/interact with it purely: enter guix environment --pure ...? Or is there a more effective way to set this up? <lilyp>guix shell --pure/container -D is good praxis tho <GrigoryShepelev[>it := this kind of software: guix package and build systems, how well does they perform, where fails etc <podiki[m]>civodul: thanks, previous versions did use package-source to get that, but now seems we can remove that in favor of the source only package <vagrantc>civodul: so, when you stay staging is "open" ... does that imply it shouldn't be committed to at other times? e.g. i have a patch that fit sthe criteria for staging or core-updates ... should i hold off till the appropriate time? that seems really easy to forget about something <vagrantc>or is it more just about making it more publicly visible that it's actively being worked on? <vagrantc>maybe i should take this question to the list :) <unmatched-paren>so, i'm trying to figure out whether Hare libraries should be native-inputs or inputs; `hare` installs the source code of packages, not the static archive, and the source code is only built when you're compiling a program or running some tests <maximed>unmatched-paren: I assume that Hare has some equivalent of system("run something")? <maximed>In Guix, such things often should be changed to system("/gnu/store/.../bin/run something"). <maximed>Here, the exact ‘/gnu/store/...’ string is target-dependent <maximed>Likewise, it's possible the source code needs to be patched but the patch is target-specific, e.g. replacing epoll (which is Linux-specific) by ppoll (which exists on the Hurd) <maximed>Additionally, while 'hare' _currently_ only does the compiling in the final step, potentially it will gain C-style incremental compilation later <maximed>Also, if hare has some equivalent of dlopen("foo.so"), "foo.so" probably needs to be substituted (target-secific!) <apteryx>vagrantc: the later I'd say (you can commit anytime to staging, this is why the 3 branches exist) <vats>roptat: Do you mean you were able to build the derivation I sent you successfully? I'd need to check it again, but the errors I got were end of file on some cpp file, iirc. <roptat>vats, I think it was the same derivation <vats>I'll check it again tomorrow. <vats>Quick question. I need to package softwares provided as subdirectories in a git repo. So they all have the same origin record as the source. I'm storing that origin record in a global variable and passing that to the source field of each such package for now. I'm thinking of writing a dummy package with source set to that shared origin record, and inherit other packages from that dummy package, which seems more elegant to me. Is there a <vats>better way (acc. to the guix coding style)? <singpolyma>The var + use you described seems more natural to me, personally <civodul>vagrantc: actually 'staging' is "open" at all times, you're right; it's just that i think we should close it soon, so in that sense it's more "open" than usual :-) <roptat>vats, using the variable is more natural than a dummy package <vagrantc>apteryx, civodul: ah, thanks for the clarification. that was a bit confusing for me :) <pranavats>singpolyma, roptat : But that global variable will be globally mutable. In a package object, it can be modified in ways well defined in guix (as any other package). <vagrantc>I need to remember to merge the ncurses variant back into the main ncurses package <singpolyma>pranavats: everything in guile is mutable, that's just the nature of an imperitive languages o <civodul>singpolyma: not "everything": symbols are read-only, strings can be read-only, records too, etc. <civodul>overall, it's usually used in a functional way :-) <singpolyma>civodul: I guess symbols are immutable, sure, I'm not sure what it would even mean to mutate a symbol... <civodul>oh i guess you were referring to mutable bindings, not mutable objects right? <civodul>does it have a PID file or a socket endpoint we could probe? <tribals>I'm not able to `guix import` any `gnu` package: <tribals>Starting download of /tmp/guix-file.b8js0P <tribals>From ftp://ftp.gnu.org/gnu/hello/hello-2.12.tar.gz... <tribals> hello-2.12.tar.gz 994KiB 1011KiB/s 00:01 [##################] 100.0% <tribals>Starting download of /tmp/guix-file.BQz0et <tribals>From ftp://ftp.gnu.org/gnu/hello/hello-2.12.tar.gz.sig... <tribals> hello-2.12.tar.gz.sig 488B 810KiB/s 00:00 [##################] 100.0% <tribals>gpgv: Signature made Пн 31 янв 2022 21:58:39 MSK <tribals>gpgv: using RSA key 24093F016FFE8602EF449BB84C8EF3DA3FD37230 <tribals>gpgv: Can't check signature: No public key <tribals>Would you like to add this key to keyring '/home/.../.config/guix/gpg/trustedkeys.kbx'? <tribals>gpg: keyserver receive failed: Server indicated a failure <civodul>tribals: hi! the problem is that gpg fails to get OpenPGP keys from keyservers <civodul>because of that it can't verify signatures, so "guix refresh" stops <civodul>that's in part due to gpg not correctly dealing with keys that lack a UID, i think <tribals>So, is there a way to work around it for me, right now? <vagrantc>the key really has no uid, but it's on the keyserver? <civodul>keys.openpgp.org for instance no longer distribute key IDs <vagrantc>oh, yeah, openpgp.org has always been a bit weird <civodul>i'd tell tribals to try another keyserver but i don't even know what to recommend <vagrantc>if you know the UID ... gpg --locate-keys might work <tribals>Is there a way to use another server (if there is one usable) with `guix import gnu ...`? <civodul>vagrantc: that's the WKD thing right? i guess few people use it? <vagrantc>civodul: right ... but it's worth a shot <civodul>tribals: maybe "guix import gnu --key-server=pgp.mit.edu ..."? <vagrantc>if whoever signed it also happens to be a debian developer, --keyring keyring.debian.org <vagrantc>keys.openpgp.org is close, but it needs some things like exposing cross-signed certificates and such <tribals>Unfortunately, `guix import` doesn't support `--key-server`: <tribals>bash-5.1$ guix import gnu --key-server=pgp.mit.edu hello <tribals>guix import: error: key-server=pgp.mit.edu: unrecognized option <tribals>bash-5.1$ guix import --key-server=pgp.mit.edu gnu hello <tribals>guix import: error: --key-server=pgp.mit.edu: invalid importer <tribals>bash-5.1$ guix --key-server=pgp.mit.edu import gnu hello <tribals>guix: unrecognized option '--key-server=pgp.mit.edu' <tribals>Try `guix --help' for more information. <civodul>vagrantc: yeah, but for the purposes of authenticating tarball (TOFU style), we don't even need that <vagrantc>civodul: does guix apply the patches debian has to workaround these problems? <vagrantc>i know guix generally tries to avoid patching upstream if possible, but it seems upstream has refused the patches and they are real problems <civodul>a patch to allow gpg to import UID-less keys? <vagrantc>i didn't think HKP actually solves... any of these problems <civodul>"gpg --recv-keys" does little more than an HTTP GET request <vagrantc>doesn't solve the general problem, but maybe you can get the keys you need from there? <vagrantc>might also have a way to extract it from keybase.io ... <vagrantc>not clear on exactly what that service provides <vagrantc>obviously, that only works for this particular case... <tribals>err, hurried: it worked for importing key, but `guix import` still not able to verify downloaded source tarbal <vagrantc>it might be interesting to maintain some sort of keyring for all the relevent guix upstreams <civodul>tribals: did you import the key in ~/.config/guix/gpg/trustedkeys.kbx? <civodul>try: "gpg --no-default-keyring --keyring ~/.config/guix/gpg/trustedkeys.kbx --recv-keys ..." <tribals>civodul: thanks, it worked. What I was missing is `--no-default-keyring` <tribals>btw, why there is no MIT license in `guix licenses`? <podiki[m]>civodul: is mesa suitable for staging? I heard in the past it was, but most recently we did in core-updates; if so I can get an updated patch done this week (unless 22.0.2 has breaking changes, otherwise the last 21.3.x I'll do) <podiki[m]>tribals: I think MIT is a bit of a less formal term, but expat is probably what you want