<marco>i am trying to learn how to use guix <marco>after a system reconfiguration earlier today tmux is not starting anymore <marco>tmux: invalid LC_ALL, LC_TYPE or LANG <marco>not sure why, it was working fine before <the_tubular>Umm, this is also a problem : ;; The container's file system is completely ephemeral, sans directories ;; bind-mounted from the host. <jgart>I was just sharing the module <jgart>to my knowledge there is no docker-like networking at the level you described <the_tubular>Yeah I know, I was wondering why there's two jgart in the channel <jgart>that might be my other client <jgart>I'm not sure. I'm not a container/linux namespaces expert <jgart>the_tubular, I would ask David or Ludo <jgart>I think David Thompson was the one who implemented it <the_tubular>I think this type of functionality would be very cool. <the_tubular>I'm still looking at the file you sent. I guess it would be possible, but It would need a bit of work <the_tubular>Long term having something for Container High Availability would also be awesome <sughosha>Hi all, is there a way to include a local patch file to a package file, while building a package with `-f`? <podiki[m]>yes, just like (patches (list "filename.patch")) in the source origin record <podiki[m]>where filename.patch is in the same directory as the package def, but could be elsewhere if you write out the path <sughosha>Oh ok. I was missing `list` there so was failing. <char[m]>How do I make cargo find rust packages installed in a guix shell <jgart>char[m], if you find out do you mind documenting what you did/found out? <jgart>It would be good to add that info to the docs or cookbook <jgart>we need language documentation like that for common lisp also <char[m]>jgart, I agree. btw for common lisp, you have to include sbcl in the shell: guix shell sbcl sbcl-alexandria. then (require :alexandira) will work <jgart>ah ok, otherwise you have no repl/compiler and just libs <char[m]>@jgart, yeah, but if I have sbcl installed on my system, that one cannot find the libraries in the shell <jgart>if you have sbcl already installed in the default profile and the shell is not pure then maybe it works with the default profile sbcl? I'll have to test that <jgart>ah funny just what I was to ask <char[m]>it does not, or at least when I tried it some months ago <jgart>yeah, I remember that being weird <jgart>char[m], there was a discussion on the mailing list about that very thing <jackhill>jgart: char[m]: I beleive it's the same for even manpages too (need man-db in the shell to pick up the pages of programs in that profile) (unless man-db has now been special cased). I think the idea is that the interperter, programming language, etc (ncurses for terminfo files, although there was talk about special casing that recently for foot) determines what environment vars get processed which is where <jackhill>I think the thing to look for in the code is native-search-paths <sughosha>Hi, there is a line in Makefile which contains $(NAME). I am trying to use (substitute*) function remove the "$(NAME)", but I'm not able to escape the "$" by a backslash, as it is saying "invalid character in escape sequence". Could anyone help me please? <podiki[m]>I always forget the exact escaping rules and where, but for matching a pattern I do think you need to escape the backslash that escapes the character you want :) <podiki[m]>something about backslashes and guile strings....? I forget, but when in doubt add another and try <sughosha>podiki[m]: It didn't give any error, but it's not changing anything at all. <sughosha>Even without escaping it's not changing anything. <podiki[m]>when are you doing the substitute? I would guess you want to add a phase after unpack <sughosha>Substitute is working fine, for other lines. Only "$(NAME)" I want to delete from a line, which I'm not able to get. <podiki[m]>you sure that part is not generated somewhere else maybe? from a configure? <sughosha>The problem is that the package is storing the header files in "/usr/include/gbinder", but I want them to be in just "/include". The makefile has like this: "/usr/include/$(NAME)". I want it to be just in "/include" <sughosha>I'm trying to package gbinder-python, as a dependency for waydroid. <sughosha>> you sure that part is not generated somewhere else maybe? from a configure? <sughosha>Yes, it's not. I can replace anything else than the "$" sign. <podiki[m]>you might need some matching for the start of the line? <sughosha>No, because first I tried to substitute only "usr/include" to "/include". It was working. But then I realised that it has one more subfolder, "gbinder". Now I'm stuck with the above problem. <sughosha>I think the only way is using a patch file. <sughosha>But just for a single line it doesn't make any sense. <podiki[m]>no, you shouldn't have to, just don't know it right now <podiki[m]>for example, I did substitute for a "\$LIB" with "\\\\\\$LIB" being the matching pattern <sughosha>I tried, but still no luck. But no errors anyway. <podiki[m]>well cause I had a backslash itself in the pattern I wanted to match <podiki[m]>all this to say I don't really know, sorry. I feel like I'm guessing at it most of the time too <sughosha>No worries, thanks for taking your time to help me. <podiki[m]>someone will know! often my procedure is to add a backslash at a time until it works :-/ <sughosha>podiki[m]: I finally did it with two backslashes. What I was missing was to escape brackets too! <podiki[m]>I swear I've had that same problem, always a black box to me <podiki[m]>ok, so that makes sense then, two backslashes is pretty common in this guile matching <sughosha>I hope I package waydroid soon for Guix. <apteryx>sneek: later tell civodul after experimenting with the original idea, relying on a version field was easier and cleaner; I was able to also rename the --system, --load and --repl initrd options: https://issues.guix.gnu.org/40998#5 ***anticomputer_ is now known as anticomputer
<anticomputer>hrmm, so say I want to build a .so in my ~/ that I have to load and re-use at some point in the future, presumably I'd want to use a guix environment with -r to build the shared lib so that any linked libs don't get garbage collected out from under the .so in the future yea? <sughosha>Hi, should `python` be in propagated-inputs, inputs or just native-inputs? I'm packaging waydroid which is written in python. <roptat>sughosha, if it's written in python, it should be in inputs, so the target python is used when running waydroid <roptat>but if it wants to run some python code during the build, it also needs to be in native-inputs <sughosha>ropat: I thought if it is in inputs it will also be used while building. Should I mention it twice then? <roptat>during a cross-build, whatever is in inputs can't be run, because it's for the target architecture <sughosha>But in my case the app is only script, I use copy-build-system for it. So I don't need it to be in native-inputs. <roptat>right, if there's no python code to run during the build, only inputs <roptat>also, you might want to wrap the binary so it uses the python from the inputs, instead of #!/bin/python or whatever <roptat>(well, that might already be taken care of by a phase, not sure) ***047AACB9C is now known as zimoun
<anticomputer>oh sheesh, so I just spent an hour forking a custom libvterm package because emacs-vterm wasn't working for me and I was convinced that I needed to build libvterm from the git ref that emacs-vterm uses, got that done, emacs-vterm still doesn't work ... many headscratchings later ... remembered my (shared between systems) emacs config sets the vterm shell to "/bin/zsh" ... d'oh, moved the setq to "which zsh" and all is well hah ***thornAvery is now known as ta
***aya is now known as gyara
<oriansj>anticomputer: think of it as the cheapest way to learn always check the simple stupid reasons first as odds are; our cleverness always ends up biting us in the ass. <gnoo>anticomputer: (executable-find "zsh") is better than calling which ***bonz060 is now known as bonfacekilz
***bonfacekilz is now known as bonz060
***bonz060 is now known as bonfacekilz
***bonfacekilz is now known as bonz060
***bonz060 is now known as bonfacekilz
<lilyp>is there something like gzless for reading gzip-compressed logs? <sughosha>Hi again, I'm able to build waydroid successfully, but the problem is that it is not able to import different python modules. I have built it using copy-build-system. Can anyone help me? <sughosha>Is there any environment variable or such to which I can add paths to the modules manually? <mbakke>sughosha: python-build-system should set such things up automatically ... without the code it's hard to tell what's going on. <mbakke>sughosha: you can use it, but override the phases that won't work, e.g. #~(modify-phases %standard-phases (delete 'build) (replace 'install (lambda _ (copy-recursively "." #$output)) <mbakke>the install phase is more complicated than that, as you'll likely need to place waydroid.py in #$output/lib/python3.9/site-packages <sughosha>mbakke: For me #:install-plan is convinient. Is there a way to keep copy-build-system but add only the needed thing from python-build-system? <mbakke>sughosha: that is possible, but somewhat complicated *mbakke looks for example <mbakke>sughosha: hg-commitsigs does something similar ... you'll need the same #:imported-modules, write #:modules as (((guix build python-build-system) #:prefix python:) (guix build copy-build-system)) and then you can (add-after 'install 'wrap (assoc-ref python:%standard-phases 'wrap)) *mbakke has to leave soon, hope to catch up again tomorrow <sughosha>mbakke Thanks. Seems complicated, but I'll try. ***sobkas_ is now known as sobkas
<kitzman>Is shepherd gonna have a new release soon? <florhizome[m]><sughosha> "mbakke: but the problem is..." <- I think phodina has tried that already, have you searched the mailing list? <lifestronaut>Does anyone know of any tutorials or guides that teach you Guix bit by bit, starting with a bare-bones config and slowly building a more complex desktop config? <bonz060`>lifestronaut: Do you mean building a guix system? Or would you want to have a bridge on top of another distro? <lifestronaut>Building a guix system, not the package manager on a different distro <bonz060`>Also, does any one here have a way of managing mailing lists that doesn't involve gmane.io/ GNUs or filtering mails using say notmuch? <lifestronaut>bonz060`: Something like the manual install, but with more post-install content when starting with a bare bones system <excalamus>bonz060, I subscribed and filter the emails into a folder. The mailing list isn't overly busy <jpoiret>bonz060`: there's piem for emacs, haven't used it but it seems pretty good <excalamus>I know that's basic. I wanted normalize it :) <bonz060`>jpoiret Thanks for this! I'll most def try to have a look at this! <gnoo>lifestronaut: for configuring guix, you'll need to learn some amount of scheme. then search api reference node for commands. it's learn as you go ;) <jpoiret>depending on how complex you want your configuration to be, you'll be able to weasel out with a minimal understanding of scheme <jpoiret>but it definitely helps you do cool things :) <acrow>For the record, icecat (running on and packaged by guix, of course) worked well to listen and chat on guix-days. <sneek>acrow, jeko says: in deed! I wanted to have a disposable system to throw away after each pair-programming session. appreciate your consideration ! ;) <blake2b>nice guix-days everyone, thanks roptat and zimoun for organizing it <efraim>and I cant wait for tomorrow too! <zimoun>I am impressed by all the amazing discussions and I am happy to see all the diverse use cases. :-) <podiki[m]>it was great, just wish I could attend more live sessions <roptat>podiki[m], just wake up earlier, easy :p <podiki[m]>I stand by my point of Guix community being top of my list for why guix and what's so great about it <excalamus>podiki, I'm glad to have "met" you today and appreciate the community you bring to the IRC. <podiki[m]>funny, in all my years online I never really talked with "strangers" and now I'm here all day :) <podiki[m]>thanks! happy to pay it forward from those that were so great when I started out <excalamus>podiki, I may have misunderstood you when you were talking about a literate config. Is that something you'd like to chat about more? <roptat>yeah, the community is a big part of why I liked and still like guix too :) <podiki[m]>excalamus: curious what you meant by problems you ran into, was it in having different pieces? I was just going to generate the config.scm from org babel, but right now it is just for one machine, so nothing fancy to generate <excalamus>this is where I think I misunderstood you. I've tried to document my work with guix using org. The issue there is that building can take a while. Since the org shell is blocking, that means your emacs session freezes until your guix stuff finishes. If you're talking about tangling a script, yes, that works fine. <podiki[m]>ah, so more literate programming of your actual guix hacking? <podiki[m]>my package writing and bug fixing is all pretty basic of a workflow so far, mostly used literate programming for config files <excalamus>the thought being that it could be a good way to help documentation, to be able to literally follow along <podiki[m]>that does sound good, a strength of literate programming <acrow>Throwing stuff out. I had been happily using stow when I tried guix-home. Incompetent management resulted in them fighting one another. Don't do this. :) <acrow>I also imagined during guix days that people were going to annouce that guix-home now enables a local store into which you can put your personal secrets. Managed, of course, using the home-guix-shepherd. Did I miss it? <excalamus>I didn't see that. I may have missed it in the first part of the day (I was asleep) <Michal_Atlas[m]>acrow: That... I missed that too, even though I've been hoping for it for a while. <excalamus>roptat, the time zone differences are a challenge. Not sure what else can be done about that <acrow>Current setup uses guix-home and syncthing. stow is there (with files safe in the filestructure) but has to be fixed up after every time guix-home is reconfigured. <acrow>Syncthing works great for me (because I have multiple cheap machines that can share things) but I feel some guilt that I don't put the work needed into reducing things to rsync (as lilyp suggests). <lilyp>That was not a suggestion, do not ask me for tips on backups! <acrow>Yes, I'm a reductionist. There, there I said it. Now let's not talk about it anymore. <lilyp>Rather than discussing software solutions, my aim was to discuss the set of files you need to back up at all <acrow>lilyp: nice work, btw. If you didn't already hear it from me. thank you. <lilyp>putting your config.scm and home.scm both into syncthing is still more reasonable than having no backup or storing entire disk images <Samuel[m]12><excalamus> "this is where I think I misunder..." <- have you seen ob-async? It doesn't work with #+calls, but for any long running tasks its a lifesaver, such as remote db queries directly from src blocks -- and you can use multiple blocks concurrently <acrow>ok -- but where do my, few, secrets go? Is this where a small container image is appropriate? <acrow>secrets are the burr under my blanket. The antithesis of declarative programming. The forbidden fruit that I think I ought be able to grasp. :) <excalamus>Samuel, yes, I have. I found that it worked for some things, but not others, like sessions. The source worries me, too. The main functionality looks like a copy-paste from the org source. <blake2b>any interesting examples of pattern-matching for bitwise operations in scheme someone could recommend? <lilyp>acrow: you want to raise that tomorrow in one of the spontaneous topics slots <lilyp>we'll have ~40 people particularly spending their time debating guix stuffs, so we'll probably get a few ideas, perhaps even a good one <podiki[m]>yes secrets would be good to figure out, keeps coming up <efraim>the best I've come up with so far is storing a blob that gets decrypted using gpg <acrow>Ack -- I've revealed too much -- it is a small fragment of a big picture that guix has done at least as well as anyone else I know of. Way better, really. <acrow>efraim: I use pass. For a time it was difficult to get the configs just right but guix has fixed all that. <efraim>my ~170 lines .ssh/config ends up dropping from ~4900 bytes to ~2800 bytes after using gpg and base64 <the_tubular>I know that there was some prerecorded ones, I'm talking about the other ones <acrow>efraim: and then you just take that base64 and put it into your guix-home (plain-file "blah.b64" "my-secrets") like thing? <efraim>I haven't yet but I think I'll just embed it as is <efraim>Probably not ssh/config but I have some other files that I'll try out first <efraim>I have some passwords that I leave encrypted for sending mail. Easier to just remember my gpg passphrase <acrow>efraim: yes, that is the reductionist ideal! one password. tidy. <blake2b>one thing I think my presentation was lacking due to time constraints is to show folks the incredible part of the docs, which is the Guile Implementation section. if you've used guile in guix but havent dove into the language itself, do yourself a favor and just go straight to the section on the compiler tower and read until the end <excalamus>blake2b, I'd watch a video of that if you recorded it <blake2b>perhaps I will. I think people don't realize that with guile, you essentially get declarative, compiled languages for free with the (define-language ...) form. its really simple to use and there are all of these high level compiler tools to play with. <paul_j>Evening all! Quick question - is there documentation explaining how I can test a patch out? I am following the problem with thermald/upower, and Maxime has kindly provided a couple of patches which should resolve it for now, while upstream sort out the problem. <paul_j>I am quite happy to work with the full source if that is necessary, but I wondered if there is some way to inject a local patch during the build. <lilyp>paul_j: currently not, but the gist of it is you download the patch-set from mumi, run `git am', build things locally and test them (in a pure evironment, vm, or similar) <paul_j>lilyp: the patches are attached to the thread about the bug, so I can get them from there. I'll give it a go, and see what happens! <ss2>Hello, and good evening. It is such a shame that I didn't manage to participate today, and tomorrow I'll just about be around for 16--18 properly discussing the future of Guix. I might join before. <ss2>I'd like to somehow jump in tomorrow, and discuss about my little work on writing a Samba service. And I'd happily would also like to use an oppurtunety to introduce myself too. It is nice seeing and hearing some real voices. <ss2>But I'm not so sure when the timing will be best to talk a bit about Samba. <ss2>Seems a bit late now and I missed the whole show today. I hope to catch you tomorrow at a better timing. <roptat>ss2, you could join during one of the "spontaneous topics" sessions :) <ss2>I thought so too, but I'm not sure if I'll manage. I'm always in bad luck with timing. <ss2>And being busy with school. Just finished my thesis. Which is actually about Guix and setting up Samba. <ss2>So I've only got my spare time to work on Guix. <ss2>no, It's a technical school. Not really a university too. <ss2>So the paper's short, and only covers the basics. <roptat>that's super cool. I hope we can have you tomorrow :) <ss2>yes, I hope so too. ^^ I basically want to give some feedback and and discuss it a bit. <roptat>paul_j, once you apply the patches, use this to build guix ^ <ss2>Unfortunately I fell a bit short on implementing the service as far as I wanted, but would like to show it still. <ss2>My problem is, that my git tree about it is a complete mess (hah!), and could either just produce some quick pastes and then later on clean up my tree a bit? <roptat>sorry, I think that's not related to your issue <roptat>just do whatever is best for you that allows you to explain what you're doing <ss2>No, I've got some personal branches and a personal channel floating around. <roptat>worktree woud allow you to work on these branches separately without having to rebuild all the time <ss2>But I kind of got messy the last month and should do some proper housekeeping at some point. <ss2>allright, I saw that today off zimoun by chance. It was the first time I heard of it actually. <roptat>but if a branch is messy, it can't help you :p <ss2>But I usually just keep my branches, and don't do that much recompiling. Only when needed. <paul_j>roptat: Thanks - building now... <ss2>okay, I will just prepare some pastes, show it off, and see what you say about it and what can be done to have it placed into Guix proper eventually. <paul_j>roptat: I am running `time` on it, so I will report back once it is complete! <ss2>I'll try to be around at 11:20. <paul_j>roptat: good - took just under 15 minutes to build. Building thermald with the patches supplied by Maxime works OK now as well. <the_tubular>Now that I'm free, is there somewhere I can get a nice roundup of what happened today ? <the_tubular>I already watched the pre-recorded talks, I'm talking about the other stuff <roptat>not yet, it was recorded, but we'll need maybe a week to get the recordings if all goes well <unmatched-paren>hello guix, i'm trying to join a matrix channel using weechat-matrix, but i'm unsure how to load the script on guix <bovid-19>is it possible to use manifests in the system configuration instead of listing the packages there? <bovid-19>or to provide a system configuration to guix weather to see if any local builds are necessary? <jgart>bovid-19, everything's possible with guix <lilyp>I don't think a manifest is a full package description, but since you'll be invoking specifications->manifest or packages->manifest anyway, you can instead stuff those into a list and proceed from there <Haider>are any of you also having problems in Qutebrowser where it wont render certain fonts?