<singpolyma>rickame: the guix releases don't really mean anything to users <rickame>ya but me and my friends are gonna learn it starting at 1.4 <singpolyma>vivien: if you find a good way to turn a package into an sexp let me know. Right now I double escape my sexps to work around it <rickame>feels like linux in 2002 when it wasnt that known but is gonna blow up soon <singpolyma>rickame: I reccommend pretending guix doesn't have version numbers. There not useful to know or think about <rickame>there's no such thing as major change vs minor change? <rickame>how do you have intuition about stability? <singpolyma>rickame: no one runs guix from a numbered version in practise. The moment you install it you run guix pull and now you just have HEAD <singpolyma>The releases are more for marketing and morale purposes <rickame>well snapshots of 'latest known good' is important <singpolyma>rickame: you can think of it as rolling release for Guix itself, yes <rickame>i think rolling kinda sucks because y ou never get a chance to use software that's $timeperiod old <rickame>i don't like software < 1 month or older than 5 years <singpolyma>You can always get any version with time machine <PotentialUser-18>On this note, if I understand it correctly, when I time-machine or change generations, I use the guix version from that commit to operate, so can I use a new version of guix while installing old software? <rickame>i get it i just dont really like it but np <rickame>there's something special and unique about a snapshot release of a known good, + minor version for fix only patches, that a rolling release can't ever give <singpolyma>PotentialUser-18: I'm not an expert there, but pretty sure time machine means using an old version of guix to install the old software <rickame>because y ou can only pull x version, but then never the y patch only thta follow <unmatched-paren`>hi guix, when my device hibernates i hear a horrible scratching sound coming from the ssd; i checked and noticed that my swap is 4gb, while my ram is 16gb; would that be related? i know this isn't specifically related to guix, but i'm wondering if there's something i can do in my config.scm to stop that? <sneek>unmatched-paren`, you have 1 message! <sneek>unmatched-paren`, rekado_ says: pascal is not bootstrappable. There’s an old unmaintained GCC frontend for pascal, which I failed to package. And there’s the free pascal compiler, which we already have. We build it with an older binary of the free pascal compiler. <singpolyma>rickame: you can keep running an older guix if you like, but then you won't get new packages or newer versions of packages. Unless you time machine forwards <singpolyma>unmatched-paren`: if free pascal is already in guix can't you just use it? <unmatched-paren`>i guess i could set it to shut down on hibernate, which would probably increase the disk's life <PotentialUser-18>Hm, also, using a frozen GUIX system, would have the problem that there's no way for security patches to get applied, if I understand it correctly. <rickame>ya, rolling updates force y ou to accept potential new bugs in exchange for new fixes <rickame>guix should really have versions that are snapshots then fix only forwards <unmatched-paren`>the problem with shutting down is (1) it happens without warning and (2) it would cause disk fsckings every time i booted from an unexpected shutdown <unmatched-paren`>that's what makes the guix/nix way much better than the arch/parabola way :) <podiki[m]>guix is not a snapshot release, it is rolling; of course you can stop rolling wherever you want but if that's not what you wnat... <unmatched-paren`>i'll make it shut down at low power for now, i don't feel like risking my data for the sake of increasing the swap... <unmatched-paren`>has greetd integration been added to guix system yet? i heard that was planned <rekado_>rickame: you still get plenty of old software in Guix because we didn’t get around to updating everything :) So you get a happy mix of stable software with the latest stuff too. <rekado_>it is expected that the stuff on the “master” branch works, but it can happen that updates break things. That’s why roll-backs are an important ingredient in this particular recipe of chaos. <PotentialUser-18>It's kinda nice, that most of the things get updated in GUIX, when there's a feature somebody actually needs. <rekado_>guix doesn’t try to partition anything <rickame>guarantee this is gonna turn into a problem growing guix <rickame>rolling release without an option for a 'stable' branch expects a compromise of fixes and new code that might intoduce regressions <rickame>just add a system that lets you guys cut snapshot releases like 1.4 that from that point forward only pulls changes categorized as bug and sec fixes <rekado_>can’t have a stable branch without lots of people committing to maintaining a stable branch <rekado_>“just” does a *lot* of heavy lifting here <unmatched-paren`>rickame: as i said: guix provides a rollback option in grub; if you break stuff, you can roll it back <rickame>i know i know just catalog my feedback homie <rickame>so if you pinned to a version, it would then lense all updates through a predicate of bug or sec fix <rickame>so you could use all tools just like normal <rekado_>the assumption is that *every* new release fixes a ton of undeclared bugs <rekado_>lots of other packages don’t bother declaring bugs or security fixes <rekado_>and very often you can’t easily backport the fixes either <rekado_>hell, packaging some software at *any* version is a terrible waste of time <rickame>well that doesn't match how i dev. i put more polish in before cutting a release than in the middle <rickame>the 'continuous' improvement has no structure. just seems endless stream of rabbit 'pellets' <rekado_>you need people to actually backport fixes, carefully test to make sure the backport isn’t actually creating new bugs, and make sure everything keeps building with all the other packages that are frozen in time and patched beyond recognition <rickame>sure, so have an evergrowing testharness to automate that part <nij->Hi! `guix describe` says I'm in commit f870977 (2022, Jan 28), but I still don't get `guix home`. What did I miss? <rekado_>rickame: I encourage you to look at the 20k packages we have. Your assumptions of what developers do does not match my experience with software as it is developed by humans. <unmatched-paren`>i'm sure it would be possible to write a guix-stable channel if you really, really wanted to, but then... what's the point? you just get slightly older versions of things. there's no stability benefit (unlike arch v. debian) because of the transactionality inherent in being a functional package manager <rekado_>rickame: sure, just saying that this cannot be extrapolated. <rickame>id like that personally. the point is that the ppl accepting updates to guix-stable would evaluate them for scope and probability to introduce regressions <rickame>the goal would basically be any code that fixes something and nothing more <rickame>so if someone is running into a bug they report, code fixing it is pulled into guix-stable, then anyone else running it can update and just get fixes <unmatched-paren`>pacman is not transactional, updates can and often do break stuff, which is probably the main reason people why people stay away from arch and derivatives (it was the reason i did, at least, and it seems like a logical reason to avoid it) <PotentialUser-18>what might be better is to collect statistics about failed builds and mark commits that have those, so then you could just set guix to not use commits that can't build stuff you need <nij->.oO( any guix home user? ..) <nij->Hi! `guix describe` says I'm in commit f870977 (2022, Jan 28), but I still don't get `guix home`. What did I miss? <rickame>guix has so much promise. it can be the biggest distro in all linux <rickame>nothing is better than declarative reproducible config in simple composable files <unmatched-paren`>when you do a `pacman <whatever>`, it literally swaps out all the files that it needs to. when you do a `guix pull/upgrade/system reconfigure`, it builds a profile in the store, creates a bunch of symlinks in /var/guix, then atomically replaces your profile in one go, which makes it really easy to implement stability features etc. there's a reason the word `dependable` is on the front page of the guix website ;) <rickame>imagine typing things into lightning box to make changes <rekado_>nij-: no idea! I can type “guix home” and have it print a reasonable error message. <PotentialUser-18>What does `guix --version` say? I know I just had a wrong path and invoked an old guix when I couldn't get my home working <unmatched-paren`>rickame: sounds like you want fedora silverblue or whatever it was called (am i thinking of the right thing?) <rickame>no i believe in guix i just know better on this <unmatched-paren`>rekado_: $ herd restart swap-***** -> "herd: service 'swap-*****' could not be found" <nij->rekado_: something like "guix home: no command" <nij->Oh nvm, guix home --help shouts a lot of stuff <rekado_>unmatched-paren`: what does “sudo herd status” say? <nij->I messed the syntax up. Should be `guix home whatever` <unmatched-paren`>PotentialUser-18: thanks :) i forget that guix already has extremely extensive docs... <nij->Can I use guix home to replace stow? <nij->I see it can use to define lots of services.. <nij->and I get lost.. not even familiar with what services are.. <nij->PotentialUser-18: would you share config :O? please :):) *unmatched-paren` is slightly worried at this point <rickame>can guix containers be as secure and performance as freebsd jails? <PotentialUser-18>Hello, does anybody have any docs or places to find how to run downloaded binaries? I know it's not the guix way, but sometimes it is inevitable and I'm really not sure how to do it. <PotentialUser-18>It always errors out with "No such file or directory" and if run with `./ld-linux`, it can never find the proper libraries, what am I missing? <gordon1>not a guix expert, but assume that there is no way around making a package with bunch of patchelf commands to fix every .so incl. ld-linux <vivien>PotentialUser-18, some free software is notoriously hard to package in guix. For this, flatpak may be a solution. <PotentialUser-18>Oh okay, ye, I heard about patchelf, and what it does, but Can't really find a good source to learn to use it. <PotentialUser-18>I've seen this in a bunch of places, but sadly it doesn't help at all really <gordon1>PotentialUser-18: it isn't particularly hard to use tool and not so convoluted, i guess man patchelf is an ok start <gordon1>workflow should be something like 1) find through ldd which libs binary needs 2) change path to those lib in the package definition use patchelf <gordon1>though it's all purely theoretical, never tried that <gordon1>actually it is in glibc, just not exposed in my path <gordon1>/gnu/store/<hash>-glibc-2.33/bin/ldd <gordon1>can i somehow expose ldd that is in glibc to my path? <nij->I noticed that some services got loaded up very slowly. For example, after reboot, it takes at least 90 seconds for the internet to start working. Anyone had this issue before? <PotentialUser-18>Have a similar thing, on my laptop guix boots almost instantly but on my desktop gdm takes maybe 3-4 minutes to show up ***the_tubular79 is now known as the_tubular
<PotentialUser-18>My solution would be to remove stuff and locate the source of the problem <PotentialUser-18>If there's anything new, that you copied or looks strange try removing it <nij->I removed almost every thing, but the error persits. It builds without error. But it isn't able to mkdir in my home dir.. <nij->From the discussion thread, it seems that I have granted too less services in the config file. <nij->I've tried the services they suggested, but didn't solve the problem. <nij->I have %base-service now.. I don't have a working wm yet. <xelxebar>nij-: Ah, that's probably it. The thread you link says that guix home expects /run/user/$UID to exist, which is created by elogind. <xelxebar>You can try throwing (elogind-service) in your services. <nij->I did that and failed. I can do it again and see what's the exact error. <PotentialUser-18>Or if you're starting out, then `%desktop-services` should sort that out <xelxebar>nij-: Hrm... First it makes sense to just check whether /run/user/$(id -u) exists <nij->Will do that after the reconfiguration! (what is that, though?) <xelxebar>The command `id -u` just prints out your numerical user id, so `/run/user/$(id -u)` expands to something like /run/user/1000, most likely. <nij->ls /run/user/1000 : No such file or directory <nij->Bummer.. reconfiguration just failed "... guix substitute' died unexpectedly. Will do it again. <xelxebar>nij-: Note, elogind probably needs to be added to your *system* services in your operating-system declaration, since creating directories under /run/user requires elevated priviledges. <nij->Oh! Adding %desktop-services this time did work.. last time it appeared to be broken because the system took some time to set things up ( I guess..), and I thought the system was broken by the updates. Thanks :) <nij->Baby! I'm ready to rock n' roll! Thanks so much for your help today. I will be back tomorrow. Gn :):) ***califax- is now known as califax
***aya is now known as gyara
<Charles[m]1>Any clue why docker containers cant use internet unless --network host ? I'm using nftables. <raingloom>/run/user/$UID/gvfs is broken again for me for some damn reason. <dp0>So I recently did a guix pull and guix system reconfigure and was wondering if anyone else has run into an issue with gnome being yellow? <dp0>I even re-installed from scratch using the latest stable from gnu.guix.org (just to make sure it wasn't from my mucking around) and even the login page is still like entirely yellow. <Charles[m]1>dp0: I'm not sure what you mean by yellow. When I upgraded to gnome 41, I noticed that my color profiles were off. try messing around with the profiles in the "color" section of the gnome settings. <dp0>Whoops. You are right, my bad. <dp0>Hmm, maybe that's what it is. Just the color profiles, but I can barely read my screen it's so yellow. lol <sneek>raghavgururajan, you have 1 message! <sneek>raghavgururajan, jgart says: OK, let's do it. I gave sneek a zopiclone. <raghavgururajan>I am probably late to this party. guix substitute: warning: bordeaux.guix.gnu.org: connection failed: No route to host ***daviid` is now known as daviid
<apteryx>interesting; the common substitute* idiom (("regex" _ group1) replacement) breaks inside a G-exp <apteryx>error: _: bad use of '_' syntactic keyword <apteryx>raghavgururajan: I think the MDC still had networking woes <apteryx>ah! about my previous error, it only manifests itself when there are no #:use-module (guix gexp) at the top of the module ***duds-_ is now known as duds-
<jeko>I don't know what guile package to choose for my package definitions. guile-3.0-latest ? guile-next ? guile-3.0 ? <lilyp>typically you want plain 3.0 <lilyp>if your package requires features newer than 3.0.2 then guile-3.0-latest <lilyp>guile-next is IIRC not intended to be used as input but rather for people wanting to experiment with it <jeko>ok ! so lets go with guile-3.0 ! <jeko>anything obvious from the definitions ? :S <jeko>I have 3 propagated inputs and the other 2 are importable <tissevert>where is this (use-modules …) ? not in jeko-packages apparently <jeko>tissevert: jeko-packages is my custom channel. I have another repo for each project defined. <jeko>tissevert: I just started the ynm-web project but when I guix shell into it, the REPL tells me (ynm-core entities) is not found (it's a module from ynm-core package) <tissevert>which repl ? do you spawn a guile into that guix shell ? <tissevert>doesn't it provide a clean stacktrace with the exact location of the import ? <jeko>ice-9/boot-9.scm:1685:16: In procedure raise-exception: <jeko>no code for module (ynm-core use-cases) <jeko>oops sorry for the copy/paste <gnoo>is the directory containing ynm-core directory in load-path? <gnoo>or did you add ynm-core to the load-path? <jeko>I believe it's added because the environment is provisionned with a package definition which has ynm-core as propagated-input <tissevert>I don't think it would add the package definition <tissevert>only what ynm-core defines in terms of environment variable <tissevert>no, you have to either define the GUIX_LOADPATH or something, or use the -L option with guix {build,shell,…} <jeko>the ynm-web definition contains (propagated-inputs (list guile-spec guile-dsv ynm-core)) <jeko>(use-modules (spec)) works. It's a module from guile-spec package <gnoo>did you try (use-cases) instead of (ynm-core use-cases) ? <tissevert>wait so that's supposed to work ? that's cool, I didn't know that <jeko>same result. the use-cases module is defined with (define-module (ynm-core use-cases)) so I expect it to require (ynm-core use-cases) <jeko>tissevert: yeah I hope it's supposed to work haha or I am totally lost <jeko>maybe I don't export correctly the modules… <jeko>guile-spec has a spec.scm at its root re-exporting some definitions <tissevert>I see, you have a guix.scm at the root of the project declaring the package, but all the actual modules are in the ynm-core folder <jeko>yes ! this guix.scm at the root allow me to spawn an env from my local sources, not from the channels repo commit thing <jeko>the inputs remain the one defined in the channel's definition <jeko>(efraim Guix Days 2021 idea haha) <tissevert>what I don't understand is where the ynm-core imported from ynm-core/guix.scm l.24 comes from 🤔 <tissevert>so the "local" devel package imports the "general" jeko-packages, which, for its definition, uses the git repos… defining the local package <tissevert>I'm sure that isn't the cause of the problem, it's just confusing me ^^ <jeko>haha ok I want to avoid having two definitions of my package at different places. So the main one is in jeko-packages <jeko>but sometimes my local work is ahead of the package definition, so I inherit and change some thing like the commit to point to <jeko>when I'm done I update the main definition in jeko-packages <jpoiret>jeko: in your guix shell invocation, try adding `guile` as a package you want <jeko>jpoiret: there I can (use-modules (ynm-core use-cases)) ! no errors <jpoiret>search pathes are set in a profile only if the relevant package is installed in it <tissevert>ok, so the usual behaviour like python and such <jpoiret>here, it's guile that sets GUILE_LOAD_PATH, so you need to add it to the profile as well <jeko>I thought it was the purpose of the propagated-inputs in package definitions <jpoiret>no, propagated-inputs only say: please also install me in a profile if that package is installed <jeko>but still guile-spec work… <jpoiret>search-paths is a plugin-like mechanism <tissevert>and also I had totally missed the fact that it was a guile package, I thought the scheme parts were only meant to define the package written in an entirely different language <jpoiret>there's a base package that can be extended by other packages, but you still need to install the base package for it to be extended by the others in the profile <jpoiret>jeko: were you in the guile-spec directory perchance? <jeko>jpoiret: nop I m in the ynm-web ons <jpoiret>well, no idea then, you could look at the GUILE_LOAD_PATH env variable in that case and see where it points <jeko>$ printenv GUILE_LOAD_PATH <jeko>returns /gnu/store/pxnb0175phxsjpz81c55njgqidg1hkgi-profile/share/guile/site/3.0:/home/jeko/.guix-extra-profiles/jeko/jeko/share/guile/site/3.0 <jeko>ls /gnu/store/pxnb0175phxsjpz81c55njgqidg1hkgi-profile/share/guile/site/3.0:/home/jeko/.guix-extra-profiles/jeko/jeko/share/guile/site/3.0 <jeko>apicheck.scm compat config container debugging dsv dsv.scm graph htmlprag.scm io logging match-bind.scm math md5.scm os scheme search spec spec.scm string term tests texinfo text unit-test.scm <jeko>Maybe I will work on the ynm-core sources to mimic the guile-spec behavior <jeko>Thank you jpoiret and tissevert for your help <tissevert>don't thank me, I had no idea what was actually going on and I actually learnt a couple things while reading jpoiret's answers so, thanks to you both : ) <fiesh>does anyone else have the mildly infuriating issue that with every update, icedove will create and default to a new profile? <tissevert>I don't, but that rings a bell, I think I read someone (else ?) talk about it here lately <fiesh>jpoiret: ah, thank you so much! <lilyp>there's a way to circumvent that: simply use Evolution :) <tissevert>but it probably doesn't do that on other platforms, so it's not a matter of client but rather of package <tissevert>lilyp: would you suggest using another distro that guix ? <lilyp>well, obviously everyone should jump ship to that one Guix derivative that's pushing out proprietary blobs 🤑️ <tissevert>do you reckon their icedove package isn't broken ? <tissevert>"MOZ_NORMANDY" ? ^^ what kind of silly name for a variable is that ? <lilyp>Well, it obviously is a reference to a dinosaur found in northern France. <fiesh>lilyp: is it better? if it a) supports caldav calendar stuff with invites and what not, and b) somehow allows you to use nvim as an editor, you got me sold <fiesh>if in addition it allows you to use it (reasonably, not tab your way through things) via keyboard instead of having to use the mouse, then I'm gonna switch this weekend <lilyp>External editors are supported. For CalDAV, I don't know if your use-case is hyper-specific, but I've been accepting invites just fine. <fiesh>no I'm just talking about accepting these awful Outlook invites and having them end up in CalDAV based calendar <lilyp>Keyboard navigation might not be the best, being a GNOME app and all, but you can at least fairly easily jump around between messages <fiesh>ok, I'll have to look into it, thanks for bringing it up <faus45>i am whant to add docker to supplementary group, but when i run reconfigure i got guix system: error: supplementary group '(unquote docker)' <fiesh>go for podman, it's infinitely better anyway and basically fully compatible <ss2>Is it me again, or is trash-cli in its current version broken? <ss2>Is anyone else having issues with it? <PurpleSym>ss2: Yep, broken for me too. Seems like the binaries are not wrapped with GUIX_PYTHONPATH. <the_tubular>fiesh: podman doesn't have the best support on guix as of now. <fiesh>the_tubular: that was fixed very recently <fiesh>the_tubular: hmm not sure if I can find it <fiesh>the_tubular: I think I was talking about #52174 that was fixed 2021-11-29 <the_tubular>rootless containers doesn't work. podman can't find iptables, and you have to manually mount the cgroup to name a few <the_tubular>Auto-updates are not working either (that requires systemd) <gordon1>so i'm trying to make simple package that have few files in the channel repo alongside with the .scm recipe that i want to install in /bin/ of that package but with (source #f) and trivial-build-system it looks like i have no access to channel repo if i try to do (copy-file (search-path %load-path ...)), am i doing it wrong? <gordon1>it is build in some sort of container, isn't it? <gordon1>can i somehow put just a local file as an input? <gordon1>oh, you actually can, this is very cool <lilyp>hasjplante03[m]: record abi mismatches should not occur in properly pulled guix <lilyp>do you run guix from pre-inst-env? <jpoiret>gordon1: the build environment doesn't have access to anything at all, no network, no files except for the store, etc... <jpoiret>generally you want to have something in (source ...) though <gordon1>well, i don't want to pull whole gentoo portage tree to get three files out of there and i'm too lazy to make my own separate repo for them <jpoiret>you need to remove the .go files corresponding to your package files <pinoaffe>hi folks, does anyone have a nice setup to automate the process of sending patches from magit to the guix mailing list? <jpoiret>they should be in ~/.cache/guile/ccache/3.something/fullpathtothefile.go <hasjplante03[m]>jpoiret those that are in ~/.config/guix/current/lib/guile/3.0/site-ccache/ ? <jpoiret>the offending files are your own, they were compiled for an older record ABI, you need to erase the compiled artefacts <jpoiret>so you need to look for files like /home/wj/stuff/proj/rc/wj/packages/ in the guile cache (the directory I mentioned above) <jpoiret>pinoaffe: I personally just do "W c" to create the patches, add cover letter or not, and edit the subject prefix if needed, then edit the cover letter and send using `git send-email` <pinoaffe>jpoiret: thanks! I'll try that next time, then <jpoiret>git send-email is already pretty good, but I wish Magit had something covering it. I'm too lazy to do it myself though (and my elisp is pretty bad) <pinoaffe>I've been creating them using "W c c", then manually copying 'm to mu4e-compose buffers one by one <pinoaffe>but it seems like that messed up the patches (yet again), because I forgot to turn of fill-line-mode before pasting <hasjplante03[m]>jpoiret i deleted the whole directory but i still get the same error, not sure what to do now <jpoiret>which directory? are you still getting the error while loading '/home/wj/stuff/proj/rc/wj/packages/emacs.scm'? <jpoiret>are you using a manifest to install those homegrown packages, or something else? <hasjplante03[m]>no, im not using a manifest. those packages are part of my guix home configuration <jpoiret>can you do `guile -l /home/wj/stuff/proj/rc/wj/packages/emacs.scm`, and does the error persist then? <jpoiret>or rather, `guix repl`, and then `(load "/home/wj/stuff/proj/rc/wj/packages/emacs.scm")` <hasjplante03[m]>ok, it seems like it is a problem with `(use-modules (flat packages emacs))` <jpoiret>i don't really know where it looks for compiled files <jpoiret>%load-compiled-path should give you hints <jpoiret>i don't think that's the proper course of action <jpoiret>that won't change anything, gc only removes dead store paths as well <jpoiret>generally, gc'ing will not have any side-effects apart from freeing up space <jpoiret>is there any .go file next to your .scm file perchance? <gordon1>is there an easy way to find module with desired function? <jpoiret>you could try using geiser in emacs but I personally just grep <hasjplante03[m]>jpoiret nope, i even search my whole $HOME for any go files and it seems like there's nothing left. *the_tubular shames gordon1 <vivien>guile-gcrypt has a really strange behavior when generating small-sized RSA keys <vivien>Up to 64 bits it complains that it’s less than 16 and aborts (!), starting at 65 it works, but sometimes for less than 64 bits it simply raises an exception and I get: In procedure generate-key: gcrypt: Échec de l'autotest <pinoaffe>jpoiret: I managed to set up git send-email and send some patches using it, thanks! <sneek>zimoun_ was last seen in #guix 2 days ago, saying: civodul, thanks. I will open an issue once I will access again to my colleague's machine. But I guess it requires a kernel update.. <cmack>my guix system had gotten into a state where `guix pull` fails and I think it's because it either went to sleep or lost power while doing a guix pull before. I have tried rolling back but I still get build errors with guix pull. `(exception system-error (value "git_libgit2_init") (value "~A") (value ("Function not implemented")) (value (38)))` <cmack>Does this look familiar to anyone? Or, does anyone have ideas on how I can try repairing it? <jpoiret>are you able to guix pull --switch-generation? <cmack>to a previous generation number? trying <cmack>hmm no, I get: guix pull: error: cannot switch to generation '96' <cmack>ah I see I've conflated pull generations with package generations... waiting for guix pull -l to finish <cmack>ok looks like I switched successfully to the one prior... I presume I should try guix pull now? <cmack>csantosb`: Is this something implemented in guix that I need to enable explicitly? <jpoiret>but guix pull upgrades should be transactional <jpoiret>as in, right now they should already be <jpoiret>since it's just a matter of building a profile and then switching to it, the switch should be atomic <jpoiret>if building the profile failed, you won't switch to it, and switching is just a matter of making a symlink point somewhere else <cmack>I feel like this is the second time I've managed to do this to this system and both times I think it was due to either power failure or a forced sleep due to the lid being shut <jpoiret>cmack: was it just a guix pull? or a guix package -u or reconfigure? <jpoiret>you can try to use /var/guix/profiles/per-user/<USER>/guix-profile-NN-link/bin/guix to directly use an older generation guix <jpoiret>if an older one works you can guix pull using it <drakonis>hm, is there any opposition to guix supporting macs? maybe off tree or something? <pinoaffe>drakonis: guix system or guix the package manager? <drakonis>i don't have a mac on hand but i think i might work on that as a side project on a vm later <csantosb>Would be great, but hard to achieve technically I guess. <pinoaffe>I think porting guix (the package manager) to os X would be great, but it seems like it'd be a lot of work <cmack>jpoiret: I've been dealing with this as I have time for over I week... my memory is it was a guix pull. I've tried rebooting into a previous system generation but that didn't fix guix pull either <csantosb>(guix foreign on top of archlinux on top of parallels on a m1 silicon device here) <jpoiret>yeah guix system generations are unrelated <drakonis>it just has some prerequisites related to things i'm doing right now <drakonis>i don't think the current daemon works with macs <drakonis>as all of the code supporting that got removed long ago <cmack>jpoiret: hmm I don't have `/bin/guix` in /var/guix/profiles/per-user/<my user>/guix-profile-nn-link <jpoiret>yes that should be current-guix instead of guix-profile sorry <drakonis>then there's all the machinery required to support it that lives on nixpkgs ***chattering[m] is now known as nickreset[m]
<cmack>does the error `(exception system-error (value "git_libgit2_init") (value "~A") (value ("Function not implemented")) (value (38)))` point to anything that's not related to the generations? I have git installed so that is a bit mystifying <drakonis>sounds like something not implemented in guile-git? <podiki[m]>anyone know how to get correct time in a guix container? ***nickreset[m] is now known as chattering[m]
<drakonis>cmack: you've done a pull and a reconfigure, yeah? <drakonis>try rollbacking and doing it again to see if a generation based on a newer commit does not have this problem <drakonis>yes, like booting into a previous generation <cmack>well I have booted into a previous generation but I haven't run the guix system --rollback. I can try booting farther back I guess <gordon1>how can i configure what gets exposed in my path? <gordon1>i have busybox installed whcih provides tools that are really limited <gordon1>can i have it but don't have it exposed in my bin instead of util-linux? <gordon1>(e.g. syncthing installation fails because /usr/bin/env version that is provided by busybox does not support -0 parameter) <lilyp>that doesn't sound like something that should happen in Guix (assuming you install both busybox and syncthing from it) <eonn>Are you installing it in a separate profile? <gordon1>i found that issue is that i put busybox explicitly in the list of packages in my system.scm <gordon1>removed it and both mdev works and all the tools are exposed from coreutils <gordon1>what service guix relies on to create XDG_RUNTIME_DIR? <eonn>If you're putting busybox in your operating-system declaration and also installing it with guix install, you'll have 2 copies of busybox in 2 different profiles <eonn>I need to package a python module for an application I'm compiling. Can I define the package in a manifest with my other deps for guix shell? <Charles[m]1>I have been banging my head against this cmake issue for months. Is there any cmake expert that could look at it with me (on a call)? <fnstudio_>jgart: hey, may i ask if there's any other guix (or guile) meeting planned in the coming days? <fnstudio_>sorry if it was passed on the ML, i haven't been following it much in the past few days <eonn>ekaitz: What are the logistics of that? Can I manage the package only while inside the shell environment? <ekaitz>eonn: if i understood your question well, you just need to define the package as any other, but in the manifest <ekaitz>then add it like (packages->manifest (list your-package)) or something like that <gordon1>how guix manages "system" groups like usb, audio, dialout, etc? <gordon1>for example i noticed that i have "disk" group <gordon1>but don't have for example "usb" or "plugdev" <gordon1>i mean i know they are kinda arbitrary <gordon1>just trying to find out where the definitions are <ekaitz>gordon1: you can set those in the config.scm file <drakonis>are you sure you haven't added that one yourself? <ekaitz>gordon1: user-account has a supplementary group field and there must be there <gordon1>oh no, it's not about what my user belongs to, more like what is required for udev/mdev <drakonis>you can find it in gnu/system/shadow.scm <drakonis>also the group is disk, which i looked up incorrectly lol <drakonis>which is why i didn't find it while grep-ing the source <gordon1>thanks, so i guess i can just extend it <gordon1>can i somehow make it part of service definition? <gordon1>like for example mdev needs a bit more different groups and it would be nice to have it there <lfam>Does anybody know the license of wpewebkit? Our package definition is ambiguous <lfam>It does the thing where it lists licenses of random files in the source code <lfam>But, it doesn't explain what the license of the program is <Ribby>What does Guix stands for anyway? <Ribby>*What does Guix stands for anyways? <Ribby>It has the letter x. Must be, experience, excellence, excellency, extra, exciting? <lfam>We can assume that it's a portmanteau of Guile and Nix <lfam>Although, the earliest code of what become Guix was called snix <vagrantc>it also happens to be pronounced in french more or less like the english "geeks" <drakonis>i dont see why people keep typing guix in uppercase <lfam>It seems to be a deep part of human behaviour, to want to transform strange nouns into acronyms <lfam>We are prone to playing word games <lfam>You also see that the name "GuixSD" won't go away even though we ditched it years ago <lfam>I also find that people want to argue over the pronunciation, as if the author's opinion is not (tautologically) authoritation <lfam>I mean, as if it's not authoritative <fnstudio>i suggest inverting the pronunciation: guile to rhyme with reel and guix to rhyme with mikes :) <lilyp>Or we pronounce guile the way the French do :) <eonn>Does anyone on GuixSD have a `which cc` that links correctly to gcc? The python module I'm trying to package assumes that cc will point to something useful, and I'm deciding whether I should set an alias on setup <drakonis>cc isnt available by default but you can certainly include a symlink <gordon1>adding mount tmpfs to /run is a sure way to brick your system, just keeping updated if someone wants to try that for some reason <drakonis>cc is not available because of the gnu build system <drakonis>if you install clang, it'll include a cc symlink <eonn>drakonis: Thanks, I'll try this out <gordon1>dunno, but after reconfigure it contained path to bsah <gordon1>refreshed it now, should boot i home <gordon1>i need to reboot the working system first <lfam>eonn: It's typical for Guix package definitions to set make flags such as "CC=gcc", or to use environment variables in a similar way. It depends on how the package's build scripts decide to where to look for the compiler <eonn>lfam: Unfortunately it's hardcoded to just be whatever "cc" resolves to. I'll browse some other packages to see how it's done <lfam>eonn: You can always patch the code in that case <eonn>lfam: This is my first time packaging in Guix, so I just don't know which way would be best practice. <gordon1>i guess there is super important symlink in /run for current profile that utilized by grub config thingy i guess? <lfam>Best practice is using make flags, but since this is a Python program, there is no make <lfam>So, then it's fine to patch the code <gordon1>well, i'm guessing here, no idea what has happened <lfam>eonn: The only thing you'd need to change would be the filename in which to perform the substitution <drakonis>because it holds the current system inside <lfam>eonn: That cc-for-target procedure is a special abstraction that provides the right compiler in cases where the user is cross-compiling <eonn>lfam: I see. In this case would I have to add a C compiler as a native input? Or does this happen automatically? <lfam>Let's examine that package to find out <lfam>eonn: That package doesn't have any non-implicit dependencies at all. I grepped, and cc-for-target is provided by (guix utils), so you'll need to import that if it's not already imported <lfam>Alright, it might be a little tricky since it's a Python module written in a language other than Python. But it's definitely possible <gordon1>drakonis: well, i don't have anything that manages "sessions" (whatever it is), so /run/user/* stuff never gets cleaned, for example keeping "on-first-login-executed" flag from guix home, so i'm trying to work around <eonn>lfam: Thank you for your help. I've been doing this just to compile an app I need, but I'll definitely try to get it on upstream once it's working. <lfam>Okay, that's great! Feel free to keep asking for help here