IRC channel logs
2023-08-23.log
back to list of logs
<efraim>we should probably bump the guix package, then the CI process will build a guix package <PotentialUser-6>guys, do you know what's the diff between `guix-profile` and `guix-home`? <iyzsong>PotentialUser-6: 'profile' (symlink trees) is an implementation detail used for 'guix package', 'guix system', and 'guix home'. <iyzsong>you can manage a profile procedural by 'guix package', or manage it declaratively by 'guix home' or 'guix system'. <PotentialUser-6>is is sort of the difference between guix package -u and guix home reconfigure ...? <oriansj>guix-profile should only be packages; guix-home can include arbitrary files such as application configurations. <oriansj>PotentialUser-6: guix-profile came first and guix-home is an extension to allow guix to manage more of the system's configuration. <coldfish>Yes, I still can't access, and there is no notification on the website, I don't know what happened. <adanska>hi! im going to try and write a package and home service for `starship.rs`, and i just want some feedback on where i should put it. I was thinking rust-apps initially, but now im thinking shellutils is probably more appropriate. what do you guys think? <adanska>fyi its a shell prompt customisation tool <iyzsong>adanska: i think shellutils is fine( <amjoseph>antipode is there a link for antioxidant? i couldn't find much except a guix-devel post with an expired link, and some experimental repos... but they involved the phrase "cargoless rust", which sounds really really exciting! <sneek>amjoseph, you have 1 message! <sneek>amjoseph, antipode says: it does: antioxidant. Even better, it doesn't use Cargo.lock either; it works like normal package definitions. <adanska>looking at the examples of rust packages in `rust-apps.scm`, it looks like they dont use gexps and use the label method. is this simply because they are older packages or does cargo-build-system demand this? <amjoseph>also, how do you avoid using Cargo.lock? crate2nix still has to use Cargo.lock to build the dependency graph, and it still uses `cargo vendor` (although technically doesn't *have* to) to download the tarballs. <amjoseph>are you folks curating the dependency tree instead? nixpkgs does this for haskell, and i think it's inevitable that they'll have to do it for rust too someday. <adanska>i think we curate it ourselves. we have to define packages for crates and then add them in to a packages' inputs <amjoseph>yeah, that's a lot of work, but in the end it's the only thing that's feasible. <adanska>im a little confused about the cargo build system. why do we have to use te old alist + sexp method with cargo-inputs? why cant we use gexps? <attila_lendvai>herd start a-disabled-service responds with "herd: error: failed to start service zigbee2mqtt" instead of a hint <janneke>ACTION still strugglin' with the self.scm build... <jpoiret>adanska: cargo packages in guix are special (and similar to go packages iirc), where you have to specify rust dependencies separately from usual guix dependencies <jpoiret>wdym by alist + sexp though? you don't use gexps to specify inputs usually <adanska>youre right, i was getting confused with build phases :p <adanska>if the whole dependency graph is described with guix packages, then why cant we just use them as normal inputs? whats different with cargo/go that means we cant use the normal way of supplying dependencies to build systems? i dont really know how cargo works other than that it resolves crate dependencies automatically, but isnt there a way of overriding that? <jpoiret>i'm not super familiar with it, but basically no, the cargo dependencies have to be treated specifically. or you need to rewrite the build system from scratch by avoiding cargo, with eg. antioxidant <Kabouik_>How is Sway started exactly when installed as default WM in Guix? My sway doesn't inherit env and I think it pertains to the way it is started. I don't remember doing anything very specific, except installing it and having that in my config.scm: https://0x0.st/H9Xe.txt <adanska>jpoiret: thanks for the explaination. id love to see the day where cargo-less rust is a thing, purely because it makes writing package defs that nicer haha <jpoiret>Kabouik_: GDM starts sessions through login shells <janneke>ACTION tests v4 patch for self.scm build split... <eidmar>Could somebody give me a hint as to why my message to guix-devel didn't get through? I've sent it over 26 hours ago, but it doesn't seem appear on any of the archives. <eidmar>I mean, should I wait a little longer, or should I try it again? It's my first ever attempt to post there, if that matters. <csantosb>I just did a 'guix pull', and then try to upgrade my python packages profile. <csantosb>I have an annoying error '/gnu/store/8wf5h68zm5lf9n157qbwdfmqz8dfpczq-texlive-font-maps.drv' <csantosb>Funny thing is when I try to remove any of the python-whatever packages, I get the same error. <andreas-e>csantosb: That sounds like an annoying error with the profile hook that is run when creating a profile containing texlive packages. What is your output of "guix package -I ^texlive" ? <andreas-e>Notice that you should not mix the monolithic package called "texlive", containing everything, and packages "texlive-...". <Altadil>eidmar: I’m not sure, but I believe the first post needs to be human-validated by a moderator, so that might explain the delay <nckx>You've been demoderadated. <nckx>I approved 2 messages for being excellent content, and one of them was probably yours. <eidmar>Yeah I seet it on the archives now. <nckx>My pleasure. Sorry for the delay. I didn't get around to checking the queue yesterday, and slept in today. <csantosb>andreas-e: the output gives nothing. I have no texlive package around at all. <csantosb>: /builder for `/gnu/store/8wf5h68zm5lf9n157qbwdfmqz8dfpczq-texlive-font-maps.drv' failed with exit code 1 <csantosb>: la compilation de /gnu/store/8wf5h68zm5lf9n157qbwdfmqz8dfpczq-texlive-font-maps.drv a échoué <csantosb>: cannot build derivation `/gnu/store/c3qgd5rynph38ay58y57rs92xxq0jb5d-profile.drv': 1 dependencies couldn't be built <csantosb>: guix upgrade: erreur : build of `/gnu/store/c3qgd5rynph38ay58y57rs92xxq0jb5d-profile.drv' failed <csantosb>I'm just running a "guix upgrade -p $GUIX_PROFILE" <csantosb>In current $GUIX_PROFILE I only have python-... packages <andreas-e>csantosb: Then I do not know. Maybe something that propagates a texlive package? But I do not find anything obvious in the code. <andreas-e>csantosb: Are you on a recent guix? The code for texlive font maps changed on August 9. <csantosb`>andreas-e: just, I just did a guix pull this morning <andreas-e>csantosb: Sorry, then I have no idea. ngz is more familiar with this code. You could send a bug report to bug-guix@gnu.org . As a stop-gap measure, you could try "guix pull --roll-back". <Kabouik_>jpoiret: I'm not familiar with how this works. If GDM starts sessions through login shells, should it automatically inherit env? I should say that I have a .bashrc, but use fish shell. The last line of my `~/.bashrc` contains `fish`, which is probably suboptimal but allowed me recycling my former .bashrc without converting everything to fish. And then I left it like that because of [reasons | laziness]. I don't see how this <Kabouik_>could be related, especially as $EDITOR is actually something that is defined in both my .bashrc and my config.fish, so probably irrelevant. <Kabouik_>Hold on, EDITOR is in fact not defined in my .bashrc, I seem to have commented that out. <csantosb`>andreas-e: I manage to reproduce the problem with a simple 'guix pack python-notebook' <charlotte112358>hi i would like to recreate the full bootstrap via mes on my x86_64 machine. anyone did this/has link to info? <jpoiret>Kabouik_: bashrc is not sourced on login, you should use .profile as recommended by Guix <jpoiret>Also, I don't think it's a good idea to make a bashrc execute fish, but well <andreas-e>csantosb: python-notebook does pull in a lot of texlive packages. Thanks for the report! I can reproduce the problem with my guix from a week ago. <csantosb>andreas-e: I have reported python-notebook, but note that python-nbconvert, and python-ipympl are affected, too. <aitzkora>Hi, I want some informations about the syntaxes #$ and #~ : is it guile or specific to guix. Somebody has an url to get info, please ? <sneek>aitzkora, you have 1 message! <sneek>aitzkora, nckx says: OK, but %build-inputs is a poorly (or un?)documented hack that is deprecated in favour of the gexp form I suggested. <andreas-e>csantosb: It is good to have a reproducible simple example, whichever of them, so a fix can be tested. <andreas-e>aitzkora: It is Guix specific; see section 9.12 of the manual. <nikolar>When guix manual refers to containers, does it mean it just uses namespaces to do an unprivileged chroot <civodul>nikolar: yes, "guix shell -C" uses unprivileged user namespaces <jonsger>ACTION finally got his Nitrokey 3 working on Guix System. Only two lines of config, but it wasn't that obvious to me... <andreas-e>jonsger: How about adding something to the cookbook? apteryx has submitted a patch to describe the yubikey setup, maybe this section could be expanded. <jackhill>huh, I see 65237 and 65302 are waiting on CI as well. Did CI stop picking up new patches? <attila_lendvai>well, that line is practically a single url in a comment. not sure what to do with it... <jackhill>ah, might be OK then? I didn't actually look at it. :) <attila_lendvai>the other one is an exact quote of an error message. line-breaking would hinder exact match searches. <attila_lendvai>i've never been too anxious about long lines, especially in comments... so, i'm the wrong person to ask... :) <attila_lendvai>well, *after* the patches applies, i.e. it's useless info, sorry. <aldum>>never been too anxious about long lines <aldum>what lisp does to a person :P <attila_lendvai>aldum, actually, i have a habit of strictly newlineing at certain points in the code. e.g. i always newline at nested boolean expressions to help the pattern matcher in my brain. in short: readability is higher priority for me than to strictly stay within the margin. <jackhill>attila_lendvai: yeah, sounds like it's not something to worry about, sorry for bothering you <andreas-e>jackhill: QA has been busy with building packages for master and has just resumed building for patches. <gnucode>hey guix, I am looking for free software solutions for a personal calendar. I was using nextcloud with guix system + docker. That still might be a good solution. Any other ideas are welcome. <nikolar>civodul: so it uses namespaces to get a blank / where it just mounts the required /gnu stufd <acrow>gnucode: There is, of course, info:(emacs)Diary. But... I know.. <nikolar>So it's way more lightweight than docker type of containerization <gnucode>acrow: I could certainly try that again...I suppose that I could use the emacs web server to generate that calendar such that I can view it at work. <gnucode>I like having a calendar that I can sync up to all of my devices. <pinoaffe>gnucode: I personally use emacs org mode for my calendar, and push it to my smartphone using ox-ical - this does mean that I cannot add items on the go, but in my personal experience that hasn't been much of an issue <jackhill>pinoaffe: After a cursory look, the emacs-sxiv one is missing the description <pinoaffe>jackhill: ah yes, indeed, I'll send a v2 <gnucode>pinoaffe: thanks for the tip. I have tried org-mode before, and it it not a bad idea to try it again... <jackhill>pinoaffe: +1, otherwise, at least for that one, I don't see any problems just reading through it. You might be able to use gexp instead of assoc-ref. Also, if you're patching the path to sxiv, it might be able to put it in regular inputs instead of propagated <gnucode>I gotta get going. thank for the suggestions. <acrow>pinoaffe +1, I wonder if anyone has tried to use syncthing (available on guix) to sync calendars and whatnot. TIL that syncthing is available on google play, which means it, at least, works on your android as well as other free phones. <pinoaffe>acrow: that could be nice, I personally just use adb to push my contacts, calendar, locations, etc to my android device <pinoaffe>I am also working on "ox-gpx", to export my fav places / contact's addresses to gpx files which in turn can be added as favorites to OSMand <acrow>pinoaffe: Thanks, I wasn't aware of adb. <janneke>ACTION builds fresh hurd-team hurd vm to test guix pull on the hurd <janneke>...still trying to hide with a brown paper bag on their head :) <vagrantc>janneke: haven't seen you before ... welcome to guix! :) <janneke>hey vagrantc, i'm here to break things <vagrantc>janneke: well, hurd is a good place for that, so i hear :) <lispmacs[work]>hi, I was wondering if there was thoughts of providing some kind of Guix package/service for NextCloud, or otherwise reasons why that wouldn't ever be done? <old>Hey I've recently update my kernel and I do not have a /sys/fs/cgroup/memory directory now <old>was there a change recently on that in the Linux kernel? <old>or perhaps Guix does not mount the cgroup fs now? <bjc>it may have switched to cgroups2 finally? <old>mounting a cgroupv1 is not working very well .. <bjc>iirc there's a way to mount a unified cgroups hierarchy that supports v1 and v2, but i don't remember the details <old>ya I'm looking a cgroups(7) <old>would be nice to have it in Guix manual tho <bjc>a change like that should have warranted a --news entry <old>bjc: ok I manage to fix this by mounting a v1 controller <old>what a mess these cgroups stuff <bjc>tbf, a switch to v2 is long overdue. pretty much everything expects it these days, and has for years <bjc>but yeah, it's a mess <old>bjc: the thing is that I made a script with v1 and I do not have much time to migrate it to v2 for now <old>but will make the migration one day for sure <gabber>do i need to do more than simply flash the official Guix Pinebook Pro image onto the SD Card and reboot? according to the hardware docs the SD card should be the first boot preference -- yet the thing keeps booting into manjaro <makx>dealing with pine hardware I very very much recommend having a serial adapter handy ;) <makx>I wish i could even get any of these images built <gabber>there's one pre-built image on the Guix website (under Download / Latest) <makx>yeah I am trying to build an image for my quartz64s <makx>I did get a rockpro64 image to boot on a rockpro64 <makx>by just flashing it on an sd and booting <makx>it is curious that it boots into manjaro though; the sd should be the first preference when it's inserted <gabber>i'll have to check. what's your problem with your quartz64? <superkamiguru>does the RK35XX series have a bootloader config? Last I checked for my Rock 5 Model B there wasn't any support for it defined in Guix yet since it has some weird changes with how the bootloader is built vs previous chips. <makx>at the mometn when running "guix system image quartz64-image.scm" the build of guix just fails <gabber>makx: what's the error? what's your quartz64-image.scm? <makx>it fails in the "make check" phase; itś not clear to me yet what the error is <gabber>if you paste the scheme file somewhere (and tell us what the error message is) we might be able to help you get it working <gabber>(by "paste somewhere" i meant upload to dpaste or similar and by "scheme file" i meant your quartz64-image.scm file) <superkamiguru>Ah I found it. So line 1331 on this file shows how some similar build steps are defined for the rk3399. If you could define a package for u-boot-rk3566 that includes the correct build options from the u-boot docs, then you could probably just use that as the efi package in your quartz64s config <viaken>Has anyone else had issues where eudev won't recognize/trigger a rule that seems correctly written? <viaken>lispmacs[work]: I don't know of anyone working on it, but I don't know of any reason it couldn't be done. <nikolar>i am trying guix in a vm and i want to use guix home <nikolar>the only packages i have in the config are ncdu, pv, git and zsh <nikolar>why is it downloading packages related to graphics such as mesa <nikolar>haven't mentioned, but it's a console only install <gabber>that sounds like a bug (and is likely being addressed soon-ish)