IRC channel logs

2021-08-15.log

back to list of logs

<podiki[m]>for a simple python script package (basically just copies the python file somewhere), what should be the python input? just "python" in regular inputs?
<maximed>podiki: That should do it, yes, though you might want to verify the shebang is patched
<podiki[m]>ah good point
<maximed>and if it has dependencies, 'wrap-program' or the like might be required
<philipper905>thanks lfam, sending this from wifi which now works perfectly!
<podiki[m]>speaking of, for things with optional runtime dependencies, does guix tend towards having all available?
<podiki[m]>(so just put as inputs and wrapped path if needed)
<maximed>if it is ‘small’, usually it is included
<maximed>If the dependency is large (e.g. an optional dependency on 'firefox' or 'guix' or 'emacs') it usually isn't
<maximed>though preferably in a way that the extra functionality provided by the optional dependency is available when the optional dependency is installed as well
<podiki[m]>right
<podiki[m]>okay, well a few packages I'm doing will probably need some helpful review, as they have optional dependencies, but are also plugins for e.g. rofi, so I'm a little confused where to put everything. right now getting it all working first
<the_tubular>Anyone know how to use SSHFS on guix ?
<raingloom>the_tubular: afaik if you have gvfs installed it should just work
<the_tubular>What is gvfs ?
<raingloom>well, sans the numerous gvfs bugs that can lead to data loss :)
<raingloom>gvfs is what file managers like Thunar use to mount remote file systems
<raingloom>it has a wrapper for sshfs
<the_tubular>I see
<raingloom>a more reliable but less user friendly method is to use sshfs directly as a fuse file system
<the_tubular>Yeah, that's what I was asking
<the_tubular>how yo use sshfs, like I used to do it with fstab on other distro
<raingloom>ohhhhhhhhhh
<raingloom>sorry, that i haven't tried. i only used it manually.
<raingloom>the info pages seem to have no mention of it. so it might be unsupported.
<the_tubular>It's an official package on guix's repo, I'd be surprised it's not supported
<Aurora_v_kosmose>sshfs is standalone, no need for gvfs
<Aurora_v_kosmose>You just need the fuse module
<raingloom>supporting file systems in the operating system description is more work than just packaging them. i did half of the work for getting f2fs working and it was hell.
<the_tubular>So what would be the easiest way of mounting something through ssh right now ?
<the_tubular>A simple bash script ? that I execute when I need it ?
<raingloom>probably
<Aurora_v_kosmose>sshfs user@myserver.com:/home/user/owo /mnt
<raingloom>i just use bookmarks in my file manager (Thunar).
<the_tubular>Yeah, I knew that. I was looking for a more permanent solution. I guess I'll just use this until something better is around
<raingloom>you could try making a shepherd service that runs that.
<raingloom>not ideal but a bit prettier and more reproducible.
<Aurora_v_kosmose>the_tubular: sshfs can be used from fstab
<the_tubular>True, guess I could try that
<the_tubular>Although I don't know what fstab does in guix
<the_tubular>This file was generated from your Guix configuration. Any changes will be lost upon reboot or reconfiguration.
<the_tubular>Could just make a script that echo what I want in my fstab, but I doubt that's a good way to solve the problem
<raingloom>it also wouldn't be mounted at boot if you did that. or at least there would be no guarantee.
<raingloom>at that point it's better to just write a service that mounts it.
<raingloom>anyways, gotta go. i hope you figure something out. if not, there is the help mailing list.
<kitzman>is there a temporary directory I can write to while building a package? nothing works apparently, not even '/tmp'
<Fare>Minor issue: my stumpwm (loaded from source, I haven't tried packaged from guix) can't locate truetype fonts from my ~/.fonts and/or other paths, like it can on NixOS. How does that work?
<Fare>Other packages I miss: dict, dictd and all their databases.
<Fare>Possibly due to grafts, I've noticed that my Guix installation is noticeably smaller than the equivalent NixOS.
<roptat>getting close to adb, libadb_host: https://framagit.org/tyreunom/guix-android/-/blob/master/android/packages/android-tools.scm#L769 :)
<Fare>Other minor issue: I don't understand when Guix does or doesn't download new package definitions, whereas I do for Nix.
<Fare>roptat, congrats!
<roptat>a few more deps and I should be able to have the latest version of adb :)
<Fare>it looks like when I do a `guix system reconfigure` it downloads new definitions, but that's not what I want usually.
<Fare>roptat, my friend & colleague drewc was recently battling go packages with plenty of transitive dependencies to include in Guix.
<Aurora_v_kosmose>A noauto mount with a Herd service would work.
<roptat>whenever you use a different guix (usually after a guix pull), or when you change something in the os declaration
<roptat>mh.. also if you've never run guix pull, it's possible every time you reconfigure, you install an older guix as the system package, and that might be what you're using to reconfigure the next time, so downgrading all the time
<Fare>roptat, yikes.
<Fare>roptat, maybe I shouldn't put $HOME/.config/guix/current/bin in my $PATH after I bootstrapped?
<roptat>oh yes you definitely should
<roptat>that's the one you pulled
<Fare>I should put it?
<Fare>before or after what's in the system?
<roptat>before
<Fare>ok
<roptat>that's the guix you should always use
<Fare>and should /run/setuid-programs be before or after my ~/.guix-profile/sbin ?
<roptat>I don't know, whatever is fine I guess, but if there's a conflict, ~/.guix-profile/sbin will not be setuid
<roptat>so probably use /run/setuid-programs first
<roptat>I've been cloning one of the source repos for 5 minutes now...
<Fare>Is there a one-stop-shop Guix-installing script that works on all of Debian, RedHat, NixOS, macOS, WSL2, etc.?
<roptat>and I got disconnected...
<Fare>I'd like to distribute some software with Guix, for the developers and/or the Mac users.
<roptat>mac won't work
<Fare>Guix doesn't work on Mac?
<roptat>guix only supports linux and the hurd
<Fare>Oops, I thought it did!
<roptat>we can't build for mac without a proprietary toolchain
<dstolfa>Fare: for various linux distros, there's a script that does the full setup, though RHEL and Fedora need some finessing with SELinux at the moment
<Fare>aha, SELinux... yikes.
<Fare>... and building free software that runs on top of proprietary toolchain is not acceptable for guix?
<dstolfa>Fare: from GNU FSDG: A free system distribution should be self-hosting. This means that you must be able to develop and build the system with tools that the system provides you. As a result, a free system distribution cannot include free software that can only be built by using nonfree software.
<Fare>dstolfa, I understand that for GuixSD, but I was hoping that Guix, like Nix, could somehow packages to help the transition out of macOS.
<Fare>But yeah, I see that it's out of scope here.
<Fare>I suppose I can deliver docker images for those users who haven't yet seen the light.
<dstolfa>i'm not sure... guix itself is a GNU project, and if it can't be built on macOS without proprietary tools then it can't follow FSDG if i understand it correctly?
<dstolfa>Fare: yeah, that's basically what i do for most things that i use guix for and need others to use
<Fare>plenty of free software can be run on macOS---they just don't constitute a complete free software operating system, that's all.
<dstolfa>yeah, but if a proprietary toolchain is needed to build said free software, it doesn't follow FSDG
<Fare>I'm pretty sure it's still free software as long as the source code is under the GPL or such and can be recompiled.
<dstolfa>free software is different from a project following FSDG FWIW
<dstolfa>see https://www.gnu.org/distros/free-system-distribution-guidelines.en.html
<dstolfa>i realize that this is for a distribution, but guix being a GNU project gennerally follows this even as a package manager
<Fare>Thanks for the URL, though I just googled it.
<Fare>maybe I was under a false sense that there was a distinction between GuixSD and Guix just like between NixOS and Nix, whereby one follows the FSDG whereas the other has a broader applicability.
<Fare>(not that NixOS is only FSDG if you don't set allowUnfree = true)
<Fare>s/not/note/
<dstolfa>i'm not so sure about that... i don't think nix considers firefox to contain non-free software, whereas guix does
<dstolfa>namely, it is extremely easy to accidentally install non-free software in firefox through the webstore, which goes against the grain of FSDG
<dstolfa>as a result, guix doesn't have firefox, and instead has icecat
<dstolfa>Fare: FWIW, nobody in guix will judge you for using non-free software, it simply an ethical stance that guix is taking. i think you'll find that everyone here supports freedom 0 quite strongly, namely that you should be able to use your computer as you wish, it's just that only fully free software can be included in upstream guix as to not promote or support non-free software
<dstolfa>IMO, macOS and Windows support would be most welcome, if it can follow FSDG
<roptat>mh... missing a header that's from libandroid_headers, but I don't understand how they're supposed to be added
<roptat>it's not mentionned in the build tool, and it's not part of any blueprint file except the one that defines it
<Fare>macOS and Windows cannot be the basis for FSDG distribution, but a free software package manager could still run on them, and I was hoping that guix understood in the latter sense would.
<Fare>maybe it's a discussion for #nonguix though.
<dstolfa>Fare: well, keep in mind that i simply contributed some code to guix, i'm not a part of the project. those that are will probably be able to give a better answer :)
<iskarian>What does "cannot build missing derivation" on cuirass mean?
<roptat>that something's wrong with offloading, probably
<iskarian>Ah, and that's an issue with the setup of cuirass rather than the actual packages, yes?
<roptat>oh found it! It's part of the build tool, just after a comment "Everything in these lists is a crime against abstraction and dependency tracking.", and I fully agree
<roptat>iskarian, I think so
<roptat>iskarian, do you mind sending a bug report? at this time almost everyone involved with cuirass is asleep
<roptat>(well, that is if there's no report for that already, but haven't seen one like that lately)
<iskarian>roptat, will do
<iskarian>I found an old report: issues.guix.gnu.org/48574
<iskarian>Huh, and the quoted commit is not in the log...
<roptat>it's a commit in cuirass, not guix
<iskarian>d'oh!
<breathein>lfam, bricewge: thanks for your help. I tried booting off a live ubuntu iso and there were still some reliability issues with networking. I reseated the caps (idk what they're called) on the wifi card, and maybe it's working better now. I suspect that there's a hardware issue, but I'm not sure.
<breathein>Also, I noticed an issue in the documentation - At the end of section 4 in the manual: https://guix.gnu.org/en/manual/en/guix.html#Getting-Started
<breathein>There is a link to "The GNU Guix Cookbook", which points to https://guix.gnu.org/en/manual/en/guix-cookbook.html#Top
<breathein>But that link gives 404, the actual cookbook link should be https://guix.gnu.org/en/cookbook/en/
<roptat>breathein, nice find!
<the_tubular>Ohhh, rtl8812au-aircrack-ng-linux-module@5.6.4.2-5.b8167e6 does that work ?
<the_tubular>I'll have to test that out later
<the_tubular>Also, great find breathein :)
<breathein>roptat: thanks :)
<breathein>thanks the_tubular
<breathein>I'd like some help running dwm and xorg on this fresh guix sd installation.
<breathein>I ran `guix install xorg-server dwm`
<breathein>But there's no startx command
<breathein>I found this irc log saying that running startx directly is tricky: https://logs.guix.gnu.org/guix/2021-02-23.log#174818
<breathein>I am open to installing some lightweight login manager, like slim. But I'd like to keep things light :)
<breathein>Any advice?
<iskarian>You would want to edit the config.scm to replace the current wm with dwm, and then `sudo guix system reconfigure`
<iskarian>breathein: ^
<iskarian>`sudo guix system reconfigure <path-to-config.scm>`
<breathein>iskarian: wonderful - thank you
<breathein>I have a feeling I'm going to really like guix once I get used to it :)
<iskarian>Usually the current config.scm is found at /etc/config.scm
<breathein>should I create a user-specific config.scm? or edit /etc/config.scm directly when I want to make changes
<iskarian>breathein, I've just been editing mine in place with `sudo nano`, but some people (smarter than I) keep it in version control
<iskarian>it doesn't really matter where it is since you supply the path to reconfigure
<iskarian>(AFAIK)
<ryanprior[m]>I'm working on a Python package that requires python-pyopenssl. During the check phase I'm getting an error like:
<ryanprior[m]>running build_ext
<ryanprior[m]>error: libssl.so: cannot open shared object file: No such file or directory
<kimjetwav>iskarian: My tendency is to keep a version in /root that I edit and reconfigure from.
<ryanprior[m]>This ring a bell to anybody? I have python-pyopenssl in my requirements, and just for good measure I put openssl in there too explicitly but this did not fix anything
<kimjetwav>iskarian: That way the one in /etc reflects the current state of the system.
<breathein>iskarian: thank you! I like the idea of putting under version control
<iskarian>kimjetwav, ah, does /etc/config.scm automatically get updated when you reconfigure?
<kimjetwav>iskarian: Yes it does. Guix has a subsystem for provenance tracking which does this.
<kimjetwav>iskarian: All prior versions of the system profile (every time you ran guix system init/reconfigure) store the config used to generate them, plus other details like the guix version (which guix pull you used) and package channels, etc.
<iskarian>Oh, that's cool!
<iskarian>I suppose that's what allows rollbacks and such
<kimjetwav>iskarian: When you roll back to a prior os state, it re-links the /etc/config.scm file to the one associated with that system generation.
<kimjetwav>Exactly.
<kimjetwav> https://guix.gnu.org/blog/2018/multi-dimensional-transactions-and-rollbacks-oh-my
<iskarian>I must admit I haven't gotten very much into actually using config.scm, past getting my VM working!
<iskarian>(as well as not doing `guix package -u` like... ever)
<kimjetwav>I've been quietly using guix since alpha, when the only option was to just rtfm and write your own config.
<iskarian>How long has that been?
<kimjetwav>Git tells me about 8 years or so?
<iskarian>oh, wow
<kimjetwav>I think I started in 0.5.0?
<kimjetwav>Back when the installer image thanked you for being brave, haha.
<the_tubular>Can't wait for 1.4 to be released!
<iskarian>How do you feel about guix's progress since then?
<kimjetwav>The provenance tracking feature for keeping versioned config.scm copies was added because it used to be common practice to use the use `special-file` to have the config you init-ed from monadically embed itself in the installed system.
<kimjetwav>Huge progress. Very impressed. It was always cool but now it's cool and easy to use! lol
<the_tubular>I wouldn't consider Guix "easy to use" But I agree with the cool part
<kimjetwav>It definitely takes some getting used to but when I look back on it after having done that, I'm blown away by how crappy a lot of other package managers feel in comparison.
<iskarian>Haha! Definitely agree, it's only "easy to use" until you get past the surface
<kimjetwav>Actually that's harsh, but yeah.
<iskarian>The issue is just that there's a lot of concepts to wrap your head around, since Guix does lots of things differently
<iskarian>Someone earlier mentioned a wiki, like Arch does. It's not a bad idea, since it would allow for a less controlled form of documentation ideal for things like tutorials
<kimjetwav>True. I used to trip constantly over the idea that the root user wasn't the system. It's so normal that if you `sudo` your package manager, you're acting on behalf of the OS.
<the_tubular>I did :P I mean I don't hate the cookbook, but I feel Cookbook is to take your from point A to B
<iskarian>Ah, sorry :P
<the_tubular>And A Wiki is more, here's X number of article you probably won't use them all, but the one that you will use, info about your issue should be there
<iskarian>And there's definitely some rough edges with things like needing 'hash guix', having to re-log to see updates in your desktop, and so on
<iskarian>The arch wiki is still my #1 goto for "How do I do this in linux?"
<iskarian>s/in/with/
<KittyOwO[m]>yeah arch wiki is great, more things need to take inspiration from it
<iskarian>I do wonder if we'll ever get a graphical frontend for the package manager
<kimjetwav>For guix, you mean?
<iskarian>Yeah
<iskarian>They're hard to do right, though. I really dislike debian/ubuntu's graphical managers. I wonder if something more like conda would be doable
<kimjetwav>Maybe? We got a graphical installer.
<iskarian>Maybe in another 8 years, haha
<iskarian>It does feel like Guix is picking up steam, but maybe it just seems like that because I'm new
<iskarian>(the novelty, and all)
<the_tubular>I would definitely focus on the rough edges than a GUI to be honest
<kimjetwav>I've never been a fan of graphical package management. I feel like aptitude is the one graphical front-end to a package manager I've ever used, and I only like it because it enables instant dependency feedback.
<KittyOwO[m]>Has anyone here gotten `Kmonad` to work? Trying to figure it out currently hmm
<iskarian>the_tubular, definitely agree.
<KittyOwO[m]>A graphical manager for Guix System would be great, I think someone was working on something like that for Nixos, long term I think Guix System can become a very user friendly (provided the person has the correct hardware)
<KittyOwO[m]>a very user friendly distro*
<KittyOwO[m]>I mean, if you would consider it a distro, regardless, a very user friendly something xD
<kimjetwav>I'm torn between wondering if user-friendliness would be aided most by helping people understand the relevant concepts, or by providing better tooling.
<iskarian>I think they definitely go hand-in-hand
<the_tubular>Does user-friendliness really drives more user though ?
<iskarian>An intuitive interface aids understanding by showing things in addition to "saying" them, and it aids in discovery
<the_tubular>"""Most Popular""" distro is like Arch ...
<the_tubular>It literally just received an installer a few weeks ago
<iskarian>The Layperson usually doesn't *want* to read a manual before using a distro
<KittyOwO[m]>user friendliness is very important, user-friendly doesn't always mean the type of garbage corporations are shoving into proprietary software, it can just be having repetitive intuitive ideas and good documentation
<the_tubular>We're going to go back to my original point. I had no problem with Gentoo's handbook for example. But it isn't the same scope as Guix's Cookbook
<kimjetwav>iskarian: Definitely. I defer the final on user-friendliness to anyone other than myself. The manual used to be a lot "worse" as well, there was a big fat section on conceptual stuff - monads and gexpressions, right up front.
<KittyOwO[m]>on this topic aaa I have no idea what I am doing, I have never touched kmonad before let along on guix system xD
<kimjetwav>KittyOwO[m]: I gave kmonad a try a while back but set it aside for the future. I'd love to get it set up properly one of these days.
<iskarian>kimjetwav, oof. I've read through the section and I still don't "get" gexpressions except on an abstract level
<KittyOwO[m]>kimjetwav: Aw, while setting that up too far front might not be good, I am quite curious what they had written lol
<kimjetwav>iskarian: Yeah, like I said, I defer user-friendliness decisions to others. Mr stumpwm/guix/emacs+gnus over here. "But first, we need to talk about parallel universes."
<KittyOwO[m]>lol
<KittyOwO[m]>I really think a lot of people have the wrong idea about user friendliness, its really
<KittyOwO[m]>it doesn't always mean dumbing things down
<KittyOwO[m]>having good documentation/wikis/ect./, having things which are just repetitive and do the same thing regardless of what you are doing
<KittyOwO[m]>its
<KittyOwO[m]>I would actually ironically use blender as a good example of good user experience, despite still needing some work
<KittyOwO[m]>the shortcuts all work on 2d mode or 3d mode, there is just a good amount of repitition in
<KittyOwO[m]>you don't have to relearn the entire program to do something slightly different
<KittyOwO[m]>its not "oh, well I am using this new tool now I have to remember these different buttons to do this same thing!" its just the same things over and over again regardless of context lol
<KittyOwO[m]>the same button will always bring up a menu to spawn things, the same button will always delete things, ect.
<iskarian>self-consistency is important, yes. (Currently why I'm considering abandoning evil-mode and just consigning my pinky to oblivion: too many plugins don't support evil-mode and the inconsistency is killing me.)
<iskarian>kimjetwav, one of these days, I will try a tiling wm... one of these days...
<KittyOwO[m]>so, consistency and really just good documentation are important
<KittyOwO[m]>arch despite being kinda bad is probably so popular because they have really good documentations, wiki, ect.
<iskarian>I wouldn't underplay the importance of having an intuitive presentation, though. There's a reason skeuomorphic controls were so good when phones were new-ish and people weren't familiar yet
<kimjetwav>Guix's command line experience is actually quite tremendous, the way sub-commands have parallel options, things which are semantically the same have identical options, etc.
<KittyOwO[m]>iskarian: seriously tho I don't understand default emacs config, it literally hurts my hand to use its insane. I need to figure out more of emacs but I will probably mostly just use it like vim anyways lol
<the_tubular>Cynic part of me would tell you arch is only popular because it's a meme
<the_tubular>And people are sheeps
<KittyOwO[m]>well, partially because of that
<kimjetwav>KittyOwO[m]: Default emacs key config makes sense when you look at the keyboard it was intended for.
<KittyOwO[m]>but also because if someone wants to use something else they are going to run into less amazing documenation and get confused
<the_tubular>Yes, it definitely has good documentation
<the_tubular>But a lot of that documentation could apply to other distros
<the_tubular>Pretty much every systemd distro out there, except nix
<iskarian>kimjetwav, oh, the command line is great, compared to, say, apt *shiver*
<iskarian>there are still rough edges, but I'm sure those will get sanded down
<the_tubular>dvorak kimjetwav ? :P
<the_tubular>I've never used emacs, I was just making a joke
<KittyOwO[m]>kimjetwav: yeah, there really needs to be something done about that tho, like
<KittyOwO[m]>perhaps emacs needs to do some bandaid tearing
<kimjetwav>What you don't want to use a text editor designed on a keyboard with 200% of the keys your current board has? lol
<podiki[m]>what was that earlier about /etc/config.scm updating? I've been using a file elsewhere for reconfigure (that will go in version control, likely generated from an org file). but /etc/config.scm is just the original. though I know you can get any generation's config through guix system
<KittyOwO[m]>imagine something based on emacs emacs but with a more sane default configuration, and modernized with something that isn't necessarily vim-like but something that isn't physically painful like it currently is (perhaps something new, gasp!) and the express support for Guile Scheme instead of Elisp, while giving more modernized terms to things like frames/buffers/ect.
<KittyOwO[m]>I don't know how I ended up with two emacs in a row, but ok then lol
<kimjetwav>podiki[m]: Hang on I'm looking it up to make sure I don't mislead you.
<the_tubular>I feel Emacs is only tailored to devs though. Maybe I'm wrong
<KittyOwO[m]>fair, but its just
<KittyOwO[m]>there is some niche missing here
<iskarian>KittyOwO[m], isn't that what spacemacs, doom-emacs, etc, do?
<KittyOwO[m]>basically I think, I haven't used them but, just, hmm
<the_tubular>But a typical workday for me is : Messing with SSH / PGP, Firewall stuff, analyzing logs. And I don't see how emacs would help me in this
<the_tubular>I push to git 1-2 a day. And I can type the full commands, don't need magit for that
<KittyOwO[m]>iskarian: interesting, not too familiar but the default Guix channel doesn't seem to include them.
<kimjetwav>KittyOwO[m]: This is the perennial debate, though, isn't it? How to please new users, without angering dorks like me who actually hardwired the emacs defaults into our motor cortex.
<the_tubular>I guess org mode would be cool
<KittyOwO[m]>also, I don't think they have Guile Scheme support, I think there was an attempt with that on emacs at some point or whatnot
<KittyOwO[m]>also, speaking of emacs, how do I even
<KittyOwO[m]>so
<iskarian>KittyOwO[m], ah, I use doom-emacs, but I use its built-in package manager; I'm new to it, so I didn't want to try and mix-and-match with Guix right off the bat
<kimjetwav>podiki[m]: Ahh, it's not config.scm, it's `configuration.scm` by default.
<iskarian>Though I still need to get in a good hour of manual reading just so I can move windows around...
<kimjetwav>The base-services set has a provenance service which stores the config used to generate the current system profile and availableises it in /etc.
<KittyOwO[m]>when I type `emacs /whatever/yeet` for example, it loads up emacs in gui GUI and the GUI allows me to `Evil-mode`, but, when I `Sudo emacs /whatever/yeet` it goes into terminal mode, and from there it doesn't have the option of `Evil-mode`?
<KittyOwO[m]>when I type `emacs /whatever/yeet` for example, it loads up emacs in gui and the GUI allows me to `Evil-mode`, but, when I `Sudo emacs /whatever/yeet` it goes into terminal mode, and from there it doesn't have the option of `Evil-mode`?
<podiki[m]>kimjetwav: not seeing what you mean (other than through guix system you mean maybe?)
<KittyOwO[m]>kimjetwav: I am pretty sure its config.scm by default?
<kimjetwav>podiki[m]: (guix) Service Reference
<kimjetwav> -- Scheme Variable: provenance-service-type
<KittyOwO[m]>either way, if anyone knows how I can do that with emacs that would be nice XD
<podiki[m]>so you mean where guix service shows you the location of a configuration? okay that I know
<podiki[m]>I mean guix system list-generations
<KittyOwO[m]>as in, get Evil-mode to be recognised in terminal mode.
<kimjetwav>KittyOwO[m]: Maybe, I'm on the debian box I use for work stuff right now. Can't look.
<kimjetwav>KittyOwO[m]: I can help with the emacs stuff but I'm hesitant to continue derailing #guix.
<KittyOwO[m]>thats fair, if you want we can talk in some other room, would quite like to figure out how to be able to use emacs in evil-mode for editing my config.scm XD
<podiki[m]>so just to summarize, I see in guix system list-generations the info about system reconfigurations, and it gives the store path where you can see the configuration.scm used to generate it (which is all very cool)
<iskarian>Am I missing something, or does `guix refresh -u <package>` not work for packages with a git source?
<podiki[m]>Kitty OwO: really briefly, I think what you are seeing is because running under root is a different environment, and usually not set to connect to X server without modifying authentication. you can open files with sudo access from within emacs of course, look at tramp (same used for ssh editing)
<seachala[m]>I was hoping to ask if there's anything I can do if I'm having a hard time getting Guix SD to boot. Currently, it's on a USB drive.
<sioonhho>recently started messing with guix, and I'm curious as to what's going on behind the scenes when use-modules is called, but I couldn't seem to find it in the source. anyone know where I could find it?
<kimjetwav>sioonhho: `use-modules` is guile's syntax for loading modules. It's not guix-specific.
<sioonhho>new to guile too if that wasn't obvious, makes sense now why I found `use-package-modules` and `use-service-modules`, but not `use-modules`. appreciate it! thx
<kimjetwav>seachala[m]: What's going wrong? What are you seeing when it doesn't boot?
<the_tubular>I forogt the name of the command, I'm trying to pass a config.scm and create a kvm virtual disk with it
<seachala[m]>kimjetwav: I'm getting thrown to a black screen with blinking underline for a cursor.
<kimjetwav>seachala[m]: Does it boot at all, like does it look like it's loading the OS after GRUB goes away? Do you get GRUB?
<seachala[m]>Right now I'm trying a USB boot, to run the install. In the past I had trouble at the last steps of the install script.
<kimjetwav>seachala[m]: Yes, but when you say it throws you to a screen with a blinking cursor, is this... before you reached the install script, or after? How early is this failure happening, is what I was wondering.
<seachala[m]>As soon as I choose the USB drive in the boot menu.
<kimjetwav>But it's booted past that point before?
<the_tubular>How did you burn the ISO ?
<seachala[m]>dd
<seachala[m]>kimjetwav: Yeah. Most if the time I used the multi boot tool "Ventoy", but plain flash drives worked before iirc.
<the_tubular>Yeah, that's what I was going to suggest seachala[m] . But dd should be fine
<seachala[m]>I recently noticed a setting in BIOS about "legacy usb boot" which us described as booting in ms-dos mode. Obvs that's not unix compliant.
<kimjetwav>Typically options like that on modern motherboards are about disabling EFI features.
<kimjetwav>MS-DOS mode means emulate old PC-BIOS behaviour.
<seachala[m]>And usually less EFI is easier, right?
<kimjetwav>Not as such, EFI just provides an interface for more general forms of hardware initialisation.
<kimjetwav>More specifically though, as it pertains to boot device selection, that'd usually mean "search for a master boot record".
<kimjetwav>You haven't re-formatted the bootable USB stick since you had it successfully reach the installed, have you?
<kimjetwav>installer*
<seachala[m]>Yeah, is fat32 usually ideal? I formatted prior to running dd.
<kimjetwav>If you run dd than it doesn't matter what you formatted it with prior, dd will overwrite that with the iso's layout.
<seachala[m]>All my devices are oldschool. 2013ish
<seachala[m]>k
<kimjetwav>seachala[m]: But so, you've booted up to the installer on bare metal in the past, right? Just so I'm understanding what has worked so far?
<seachala[m]>I'm a bit out of practice installing OS's on real hardware. Yeah, I have gotten to the installer in the past on this laptop.
<kimjetwav>And since doing that, you've not done anything else to the USB?
<kimjetwav>seachala[m]: Also no worries, just trying to make sure I understand what's what in this situation.
<seachala[m]>Oh, I haven't had success with this particular USB. In the past I used an external SSD with a multiboot setup.
<seachala[m]>Think the USB firmware could be incompatible for this use case?
<kimjetwav>No, no, I just thought if you'd used this particular USB in the past, we could isolate what had changed such that it wasn't working now.
<seachala[m]>I'm currently double checking if diff iso's have the same issue
<kimjetwav>seachala[m]: So can you link me to the file you downloaded?
<seachala[m]>for guix? I chose latest from tonight
<kimjetwav>So the latest isn't necessarily nightly.
<kimjetwav>The latest is, specifically, manufactured via the continuous integration system.
<kimjetwav>There could be multiple per day.
<seachala[m]>Is there also a nightly? I'm hoping to learn Guix inside and out.
<kimjetwav>No, there's no nightly. There's "stable" which is just, when they stick a pin in it and call it a new version, and there's latest, which is the CI system pumping out a new iso from the latest commit.
<kimjetwav>These are the details of the latest: https://ci.guix.gnu.org/build/382117/details
<seachala[m]>my file is 3k8r5r36864dji7jlp7...
<kimjetwav>Yeah, so it's 36h old. But the exact age of it doesn't matter to the install you do.
<kimjetwav>It's like Gentoo, all that matters is that you get the latest guix version while you're in the installer env.
<seachala[m]>Was thinking of Gentoo for a second device lol
<kimjetwav>Are you on a Linux distro right now?
<kimjetwav>Actually it doesn't matter, could you tell me the device label of the USB you made?
<seachala[m]>kimjetwav: Like the label used in the "Devices" section of the file manager GUI? By default it changed to "Guix Something amd64"
<kimjetwav>Okay, as long as it successfully serialised it to the stick.
<kimjetwav>What model laptop do you have?
<seachala[m]>kimjetwav: Lenovo G580
<ArneBab>KittyOwO[m]: keep in mind that the namespace /gnu of the *packages* is of the packages and the derivations created with them.
<ArneBab>KittyOwO[m]: you don’t want to use Emacs without CTRL mapped to capslock. Luckily most desktops provide a checkbox in the keyboard settings for that.
<ArneBab>the_tubular: there are also more and more writers who discover their love for Emacs.
<KittyOwO[m]>ArneBab: Yeah, I know how to use emacs for editing root files now by just opening emacs without root lol , also yeah maybe emacs will be less insane if I remap my keyboard for it. I am planning on reconfiguring my keyboard using Kmonad but I can't figure out how to get it to work lol
<the_tubular>True, but most writers are probably using Microsoft Word ...
<ArneBab>… which shows that the quality of the tool isn’t the main issue for most :-)
<the_tubular>I just finished a University literature class saw only Macs and Windows :/
<ArneBab>Emacs could be running there and injecting some sanity :-)
<KittyOwO[m]>hey, that's not fair, I think I have heard of a small number of writers still using typewrighters :P
<ArneBab>(that’s one main reason why I use Emacs: It is the program that’s most likely to accompany me wherever I’ll go in the future)
<the_tubular>There was a guy who got some mean eyes because he had a mechanical keyboard
<KittyOwO[m]>ArneBab: Maybe, but, emacs really needs to do some bandaid tearing on the default configs. For a community like this thats not that big of a deal, we are all willing to configure stuff to our liking in great detail, but, for someone just wanting to write having more sane default configs is more important
<KittyOwO[m]>the_tubular: wait what
<KittyOwO[m]>thats
<KittyOwO[m]>probably a really good thing to have for writing wut
<ArneBab>I have a mechanical keyboard …
<KittyOwO[m]>was it just because of the loudness?
<the_tubular>In class ?
<the_tubular>Yeah
<ArneBab>gummi rings under all keys
<kimjetwav>That's when you gotta lean into it even harder and buy one with buckling springs.
<KittyOwO[m]>I guess I can kinda see why some people might not like the loudness if it was a notably loud one lol
<ArneBab>KittyOwO[m]: I used to run a heavily modified Emacs, but nowadays I’m much closer to vanilla emacs.
<KittyOwO[m]>lol
<KittyOwO[m]>ArneBab: ye, that reminds me of what I did with Qutebrowser (my browser of choice so far)
<the_tubular>What do I need in my config.scm to spin a VM from it ?
<KittyOwO[m]>initially I had the configs wayyyy different from default, but, gradually my config began to converge to the default config LOL
<ArneBab>here’s the minimum config I think you should really have: https://www.draketo.de/light/english/emacs/babcore
<ArneBab>(though I made that leaner later — I’ll see whether that is online)
<kimjetwav>the_tubular: When you say spin a VM from it, do you mean have a default virtualised service?
<the_tubular>I don't know what that means
<kimjetwav>Like, do you just want to make VMs under Guix? Or do you want to have like... a VM that provides a system-wide service?
<the_tubular>I want to make a virtual disks out of a config.scm and then give it to a VM to boot off from
<ArneBab>KittyOwO[m]: this is what you should *really* always have: https://www.draketo.de/software/babcore2.el
<kimjetwav>Because if all you want to do is make VMs, you can just install qemu in your own personal profile and use that.
<kimjetwav>Ooh, I see, you want a config that will work in a virtual env.
<kimjetwav>VM*** Not a python thing, sorry.
<the_tubular>Yes
<kimjetwav>It's been a while since I've written one, but you can specify kernel modules to include virtio modules, and an initrd to match.
<the_tubular>Just a small VM so I can do some networking stuff with it
<the_tubular>Is there an example of that kimjetwav ?
<kimjetwav>So one thing you could do, is you could crib from the VM images they provide on the website.
<iskarian>Is there already a proc that computes the hash of a directory?
<kimjetwav>iskarian: guix hash -r
<kimjetwav>the_tubular: Basically download the qemu image they provide and take notes on how they've set it up.
<the_tubular>The qemu image has a config.scm in it ?
<kimjetwav>the_tubular: I don't have the config I used back when I was running a qemu service.
<kimjetwav>the_tubular: Of course, it's a bootable guix system.
<the_tubular>Can I get that file without downloading the whole iso ?
<the_tubular>Err, guess it's not an ISO
<kimjetwav>the_tubular: Yeeees... it's in the guix git tree somewhere.
<kimjetwav>Let me have a look.
<iskarian>kimjetwav, rather I mean a procedure to call from guix code
<kimjetwav>Oh, yes again, but I'd have to look it up. It's the same code that gives you the command line, it's just called something slightly different internally.
<kimjetwav>the_tubular: https://git.savannah.gnu.org/cgit/guix.git/plain/gnu/system/examples/vm-image.tmpl
<the_tubular>Wow, thanks a lot!
<the_tubular>Watch me delete multiple things until it doesn't boot :P
<kimjetwav>iskarian: https://git.savannah.gnu.org/cgit/guix.git/plain/guix/scripts/hash.scm
<the_tubular>I've skimmed through it and apart from : (service spice-vdagent-service-type) I don't see anything else that is too "VM specific"
<the_tubular>They remove network services at the very bottom which I might (?) need
<kimjetwav>The more VM specific stuff is mostly pertinent for achieving paravirtualisation.
<the_tubular>Is that nested VM ?
<breathein>I found a very minor error in the cookbook, section 2.1.2.2 'GUIX_PACKAGE_PATH'
<breathein>4th paragraph, which reads "Create a directory, say `~./guix-packages` and"
<breathein>`~./guix-packages` is incorrect
<breathein>It should read
<breathein>"Create a directory, say `~/guix-packages` and"
<breathein>If this kind of feedback is more annoying than helpful, lmk :)
<breathein>I watched the MIT video intro to LISP, and went through section 1 of the cookbook. This project is so cool :D
<breathein>And LISP is cool, too. New to me
<kimjetwav>the_tubular: No paravirtualisation just means that you can, for example, load a series of kernel modules which will allow the guest kernel to less indirectly access host resources.
<the_tubular>Got it
<kimjetwav>the_tubular: These are the ones that guix uses by default '("virtio_pci" "virtio_balloon" "virtio_blk" "virtio_net" "virtio_console" "virtio-rng"))
<iskarian>kimjetwav, thanks :) I was hoping there was a non-script interface, but that'll have to do!
<kimjetwav>iskarian: Yeah. It's basically just a programmatic walk through of generating such a hash that doesn't choke on things you don't normally care about like git dirs and stuff.
<yoctocell>sneek: later tell iskarian: re `guix refresh -u', I have exprienced the same issue lately, so you're not alone :)
<sneek>Okay.
***edmrk is now known as fren
<vivien>Hello, I’d like to depend on guile 3.0.7 in my program because I’d like to use the new and shiny (system foreign-library), but I don’t know how to put that in my package definition. I have ("guile" ,guile-3.0-latest), but it still finds guile 3.0.2
<selvodka>noob here how wold i install youtube-dl om Nix-on-Droid ?
<selvodka>*on
<selvodka>or pip ?
<kajurea>noob here , how i would i install yt-dlp on nix-on-droid ? Please
<MysteriousSilver>Hello! this is the channel for the Guix distribution, you might've confused it for nix :D
<vivien>Solved: I had guile 3.0.2 in native-inputs too
<sioonhho>I've seen in people's configs a package passed to `use-package-modules` and also to `packages` in `operating-system`, looked around but I can't figure out if there's a difference between the two or if they're two ways to do the same thing
<DigitalKiwi>can i install guix with nix?
<bricewge>There was several PR to add Guix to Nix, last time I checked none had been merged unfortunatly
*DigitalKiwi am totally not planning to install guix to my phone that has nix-on-droid just to answer kajurea question
<MysteriousSilver>DigitalKiwi: yup, but you'd have to use the installation script/do the installation yourself (instead of installing it with nix)
<MysteriousSilver>and since /etc is not writable, you'd have to manually add the systemd service
<DigitalKiwi>is there a guix-on-droid
<DigitalKiwi> https://guix.gnu.org/blog/2018/guix-on-android/ ooh
<DigitalKiwi>drakonis: did you mention some guix overlay at some point?
<drakonis>i have, yes
<drakonis>DigitalKiwi: https://github.com/emiller88/guix
<DigitalKiwi>thx
<drakonis> https://github.com/yoctocell/guix
<drakonis>use this instead
<drakonis>DigitalKiwi ^
<drakonis>there are fixes in it
<lfam>Digging out ancient tabs from the codebase
<podiki[m]>hi guix, some questions on mcron services. where does output go by default, to the system log? (e.g. running a command that would output to stdout normally) or do you have to redirect explicitly
*bricewge wiped his disk by resuming with mounted filesystem
<lfam>😔
<lfam>Resumed from hibernation?
<bricewge>Yes
<bricewge>I was debugging the imitramfs code
<bricewge>Now let's try to repair a btrfs filesystem
<lfam>Let us know if we can help at all
*lfam does (hopefully) final round of testing for #46602 (dealing with old unsupported openssl-1.0.2)
<lfam> <https://bugs.gnu.org/46602>
<podiki[m]>I'm writing a quick mcron service to run fstrim weekly, for the command to run is just "fstrim" okay or should it be like "/run/current-system/profile/sbin/fstrim"? or somehow a store path?
<lfam>I would just use "fstrim"
<lfam>The maintenance.git repo has a lot of real-world examples of this stuff: <https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/hydra>
<lfam>That's where the Guix project infrastructure is configured
<lfam>So, in that repo, there is a "gc-job" defined, which garbage collects on the build machines.
<lfam>And there, we just do "guix gc -F 40G"
<lfam>... for example
<podiki[m]>yeah, the gc example is in the manual, but wasn't sure since that is part of guix while other examples use things like (execl (string-append #$findutils "/bin/updatedb")...
<podiki[m]>in the maintenance repo also (string-append
<podiki[m]> #$guix "/bin/guix gc -F"...
<podiki[m]>but I'll just try plain "fstrim" and see if it works later I guess
<raghavgururajan>lfam: `guix gc` cleared the shepherd and booting issue. :)
<lfam>podiki[m]: I guess that, if you don't use a gexp ( for example #$findutils), there's no guarantee that your program will exist
<lfam>Like, what provides fstrim? Will it be available?
<lfam>So, your concern is probably correct
<podiki[m]>right
<lfam>With `guix`, we can be confident :)
<podiki[m]>fstrim is in util-linux-with-udev
<lfam>raghavgururajan: That's good that it's working now! But it's really weird... it would be great to understand what happened and if there's a change that it could affect more people
<lfam>I mean, if there's a chance...
<podiki[m]>so the pattern is something like (string-append #$module "/bin/prog") it seems
<podiki[m]>okay, let me try that for good practice...
<lfam>There's also file-append, which is a little simpler. I'm not sure if it's just syntactic sugar on gexps or what
<lfam>The G-Expressions manual section explains them in some detail
<muradm>hi guix
<raghavgururajan>lfam: Yeah, its so weird. I was also using offload. Not sure if wrong store item was exported.
<lfam>Huh
<drakonis>hello folks
<muradm>%setuid-programs put programs in path, is it possible to have a setuid'ed program that is not in default path?
<iskarian>Hello Guix :)
<sneek>iskarian, you have 1 message!
<sneek>iskarian, yoctocell says: re `guix refresh -u', I have exprienced the same issue lately, so you're not alone :)
<iskarian>sneek, later tell yoctocell: As far as I can tell, `guix refresh -u` never had support for git-reference; there are 2K packages with git-reference now, so we should probably have support. I'll seeing if I can write a quick PoC...
<sneek>Got it.
<lfam>sneek: botsnack
<sneek>:)
<iskarian>thanks ;)
<yoctocell>iskarian: it doesn't have an updater for git-fetch, but it doesn have one for github urls. I was getting a weird error messasge when trying it on a package hosted on github. If the source type was unsupported it would display a warning saying "warning: no updater for PACKAGE".
<sneek>yoctocell, you have 1 message!
<sneek>yoctocell, iskarian says: As far as I can tell, `guix refresh -u` never had support for git-reference; there are 2K packages with git-reference now, so we should probably have support. I'll seeing if I can write a quick PoC...
<yoctocell>s/doesn/does
<aadcg>I found out that python publishes its docs in multiple formats, including info. this sounds useful for guix. what do you think?
<yoctocell>I tried to write a generic updater for git sources; the hard part is verifying the checkouts
<yoctocell>guile-git doesn't provide an easy way to verify a signature attached to a tag
<yoctocell>I would have to resort to calling 'git verity-tag' with system*
<iskarian>I mean, in practice, tags aren't verified anyway
<iskarian>it would be a nice-to-have though
<iskarian>and the majority of commits I see on github aren't "verified"
<yoctocell>but, when using guix refresh -u on packages with `url-fetch', it always tries to verify the tarball
<yoctocell>the git updater should try to do the same thing with tags
<yoctocell>but yeah, nobody really verifies tags or commits
<iskarian>How useful is that, though? The url-fetch updater is checking against a separate signature file
<yoctocell>in the same way that `guix pull' verifies the git checkout
<iskarian>Hmmm, how *goes* `guix pull` do it?
<iskarian>s/goes/does/
<yoctocell>guix pull uses guile-git to verify every single commit
<yoctocell>and looks at the pgp keys in the keyring branch
<yoctocell>see the (guix git-authenticate) module
<iskarian>Where would we get the pgp keys to verify against for some random git repo?
<yoctocell>download it from a keyserver, I guess, that's what guix refresh -u does with tarballs anyway
<yoctocell>it does mean that if a key cannot be found on a keyserver, you cannot update the package with guix refresh
<lfam>With Guix, there are humans who decide which keys are valid. For 3rd party Git repos, that crucial piece is missing, making the signatures basically worthless
<lfam>Now, each package could include some metadata about which keys are allowed to sign tags
<yoctocell>which is the case for guix refresh -u on packages using url-fetch
<lfam>If nobody is deciding which keys are valid, then security is reduced to the github's own "who can push" authentication system, which is equivalent to what we have now
<lfam>It's definitely worth exploring how to implement this for `guix refresh`
<aadcg>this would be super useful, I thought about it the other day too
<lfam>Even for signed tarballs, aside from GNU and Linux and a handful of other projects, there's very little value to the practice since the question of "which key is allowed to sign tarballs" is not answered meaningfully
<iskarian>So, yeah, I think there would be no harm in implementing a git-fetch updater without verification, and later add it if/when we figure out a meaningful way to do it
<iskarian>One thorn in a git-fetch updater is that guile-git doesn't support shallow checkouts
<lfam>And as Guix demonstrates, a real codesigning system based on PGP requires a large amount of 3rd-party code, not provided by the PGP implementation
<lfam>I think it's a dead end
<lfam>Real security needs to be automatic. It can't require significant software development on the part of downstream users
<lfam>It's like backups
<lfam>It's either automatic or a phantom
<clone>Has there been any work towards packaging gtk4? I looked at making a definition for it and I think it needs an updated glib. In glib definition there are comments about 'core update cycles', is one of those coming up?
***iyzsong- is now known as iyzsong
<lfam>clone: Yes, check the wip-gnome branch: <https://git.savannah.gnu.org/cgit/guix.git/log/?h=wip-gnome>
<lfam>There is a core-updates cycle being worked on right now, but it won't include GTK 4
<lfam>This cycle will include glib 2.68.0
<lfam>(Check the core-updates-frozen branch on savannah)
<clone>Thanks!
<leoprikler>w.r.t the commit sign problem, most forges do have a way of tracking keys on a per-user basis
<lfam>Yeah, that's true. Github knows which key is mine
<leoprikler>so they will display a checkmark if the signature really comes from l337-h4ck3r@evil.com
<lfam>But I don't they know whether or not I'm authorized to sign code for the 'guix' repo
<lfam>I mean, I don't think they know
<lfam>So, there's not much value in checking those signatures from github's point of view
<leoprikler>I think from their point of view it's "if you can push, you can sign, yolo"
<lfam> https://docs.github.com/en/github/authenticating-to-github/managing-commit-signature-verification/about-commit-signature-verification
<lfam>I think their system is purely based on "who can push". Codesigning authorization doesn't seem to be handled at all
<lfam>I mean, it makes sense
<lfam>What's the difference between security based on an SSH key vs a PGP key?
<lfam>(There is a difference but I don't think github cares about it)
<aadcg>you can have an ssh key as a subkey of a pgp key
<aadcg>both rely on the same encryption algorithms afaik
<aadcg>the usual RSA, ECC,...
<lfam>Well yeah but they do totally different things
<lfam>And so you design different security models based on them
<ruffni>does anybody by chance know which package provides the tool called pyrcc5 (which translates qt-resource files to pyqt5 applications)?
<aadcg>pgp identifies a person so it's usually used for commit verification, etc; ssh identifies users who can log on machines
<aadcg>so for example, you should have a single pgp key; but you should have a different ssh key for every machine you have
<aadcg>notice that you can have (multiple) ssh keys as subkeys of a pgp key
<muradm>hi guix, i found guile-inotify and guile-inotify2 in the wild, but none of them are packaged for guix
<str1ngs>should be easy to package :)
<muradm>str1ngs: sure, just wander why such common thing is not available in guix/guile
<muradm>does guix use inotify at all?
<str1ngs>muradm: most guile projects exist in guix. this might not just be used often. all the more reason to package IMHO
<muradm>no inotify use in guix source base.. :)
<str1ngs>I think the question is more, how many users use a package. not if guix proper uses it :)
<muradm>ok then if i package guile-inotify, how can i use it in gexp->script for instance
<muradm>or (program-file
<ruffni>muradm: not sure if your question is really understandable. what are you trying to do? if you package it, you'll be able to install it to a guix profile (and use the guile library as you normally would -- with a (use-modules) block)
<muradm>ruffni: in my guix system configuration i want to have a script which will use inotify facility to wait for file changes, so i can make that script with (gexp->script or (program-file, when i start writing it, there is no inotify by default in guile, if i package it, can i reference that package in (use-modules some how? for instance if i want to run let's say bash in my gexp->script, i do #$(file-append bash "/bin/bash") i don't
<muradm>install bash anywhere, it gets handled by guix to make bash package available
<muradm>suppose i made guile-inotify package, i want to do something (gexp->script "scr1" #~(begin (use-modules #$(guile-inotify-whatever)) .. of course this is wrong example
<muradm>just to illustrate the idea
<muradm>hmmm, theres module-loadpath in (gexp->script
<ruffni>i think this would work as long as you guile-inotify package is amongst system-wide packages? i am not an expert, though
<muradm>ruffni: that is not an option
<leoprikler>you can wrap your script to fix up GUILE_LOAD_PATH
<leoprikler>that's how we usually do stuff round here
<muradm>most likely (program-file "prog1" #~(begin ....) #:module-path (append-my-guile-inotify %load-path)) something like that is the way
<muradm>leoprikler: could you point to example in guix src?
<leoprikler>muradm anywhere that uses wrap-program or wrap-script :P
<muradm>leoprikler: they are used in packages only, will (wrap-script or (wrap-program wrap a gexp->script or program-file?
<muradm>also, why not use module-path argument for gexp->script?
<leoprikler>I'm not quite sure, but there's stuff that you'd usually use for builders vs. stuff that you want installed
<leoprikler>wrapping environment variables meaningfully usually results in something wrap-programesque
<leoprikler>although there are some guix-generated config files (e.g. shepherd configurations) that are just regularly printed scheme code
<str1ngs>I don't think inotify needs to be system wide. it should work like the command line program inotifywait
<muradm>leoprikler: tests/gexp.scm: 1284 vs 1312 i think (with-extensions
<muradm>is better
<leoprikler>whatever floats your boat, I guess
<muradm>str1ngs: inotify is api in the end of the day like popen or stat, of course you can use programs like inotify-tools, but it is a) not very efficient starting additional program b) not very clean to parse output of some program, if code is going to be written in scheme, would be more correct to have a binding for that
<leoprikler>and if there's no scheme code, you can still use FFI :P
<muradm>looks very long to use ffi right from script https://github.com/ChaosEternal/guile-inotify2/blob/master/linux/inotify2.scm :)
<muradm>which one is better to package? above ffi version or something like this https://github.com/b4283/guile-inotify ?
<cossidini>i have a pretty fresh install of guix system. when i try to clone a repo from gitlab (inkscape) i get "problem with ssl CA cert (path? access rights?). any idea what is wrong?
<leoprikler>We obviously need guile-inotify3 written with (system foreign-library)
<leoprikler>cossidini: nss-certs missing?
<cossidini>leoprikler: that's what i thought. but it was already installed
<leoprikler>installed where?
<cossidini>/gnu/store
<leoprikler>which profile?
<cossidini>how do i check that?
<leoprikler>usually you'd check it the other way round, i.e. "is nss-certs in a given profile" using guix package -I
<leoprikler>that's an upper-case I for "list-installed" IIRC
<muradm>cossidini: you will need something like (operating-system (packages (append (list nss-certs screen linux-pam) %base-packages)) ... ) in your configuration.scm
<cossidini>muradm: that's why it was already installed. but let me double check
<cossidini>i guess somehow i deleted it from there
<cossidini>sorry
<muradm>leoprikler: why guile-inotify3? are all packages suffixed with guile major version?
<leoprikler>no
<str1ngs>muradm: I meant you can use install guile-inotify as a user land package. nothing more then that
<str1ngs>muradm https://github.com/b4283/guile-inotify used FFI too in the form of a module extension. which is probably better then just dynamic-link . but probably do the job though.
<str1ngs>actually the module extension is not FFI really. correcting myself here.