IRC channel logs


back to list of logs

<rickame>1.4 eta pls?
<rickame>so excite
<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?
<rickame>sounds like chaos
<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
<rickame>that's rolling update right?
<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
<singpolyma>Well, that's not really relevant with guix
<rickame>i don't like software < 1 month or older than 5 years
<singpolyma>You can always get any version with time machine
<rickame>i like other ppl to find 0days
<rickame>ya but that's not really a solution
<singpolyma>It's kinda the point around here :)
<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.
<unmatched-paren`>yes, thank you, sneek, for reminding me :(
<unmatched-paren`>(i'm going to try a different approach to bootstrapping nim... ;))
<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
<unmatched-paren`>singpolyma: problem: freepascal is built from opaque binaries
<unmatched-paren`>because nobody was able to bootstrap it
<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.
<unmatched-paren`>s/the disk's life/the disk's life, as a bonus/
<rickame>ya, rolling updates force y ou to accept potential new bugs in exchange for new fixes
<rickame>the 'never quite stable lol' model
<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`>rickame: you can always just rollback in grub, tho?
<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`>and i'll take the opportunity to remove gnome :)
<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.
<unmatched-paren`>hm, what? my swap couldn't be started after i reconfigured...
<unmatched-paren`>slightly worrying
<unmatched-paren`>should i be worried?
<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_>unmatched-paren`: swap file?
<unmatched-paren`>swap partition
<rekado_>unmatched-paren`: does it exist…?
<rekado_>guix doesn’t try to partition anything
<rickame>guarantee this is gonna turn into a problem growing guix
<unmatched-paren`>yes, it does exist
<rickame>rolling release without an option for a 'stable' branch expects a compromise of fixes and new code that might intoduce regressions
<rekado_>“growing guix” is key here
<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
<rickame>ya but that's the VALUE in it
<rickame>the rallying post
<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
<unmatched-paren`>(so does nix)
<rickame>you're not seeing it
<rickame>it's not meant for you
<rekado_>I agree that there’s value in it
<rekado_>no argument here
<rekado_>but it’s gotta be done
<rickame>i wonder if it could be automated
<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_>take just linux as an example
<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
<rekado_>so no: this cannot be automated
<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
<unmatched-paren`>debian has those kinds of resources, guix certainly doesn't
<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.
<rickame>not assuming, just saying how i dev
<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
<rickame>ya that's good too
<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
<rickame>hammer rock grunt
<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
<rekado_>nij-: what do you get?
<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"
<unmatched-paren`>it was working literally five minutes ago
<Charles[m]1>How to run containers with podman without root?
<unmatched-paren`>i'd just reconfigured before...
<unmatched-paren`>it worked then
<nij->rekado_: something like "guix home: no command"
<unmatched-paren`>how to roll back to a previous system config?
<rekado_>nij-: what does “type guix” say?
<PotentialUser-18>The help says `guix system roll-back`
<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...
<unmatched-paren`> - swap-9e5a4ef1-6d5d-48b7-bbff-d26ec59dbc0b
<unmatched-paren`> - term-auto
<unmatched-paren`>(along with all the other sections ofc)
<unmatched-paren`>i'll try doing a roll-back
<nij->Can I use guix home to replace stow?
<PotentialUser-18>I literally did that same thing
<nij->I see it can use to define lots of services..
<nij->and I get lost.. not even familiar with what services are..
<unmatched-paren`>rolling back didn't work...
<nij->PotentialUser-18: would you share config :O? please :):)
*unmatched-paren` is slightly worried at this point
<unmatched-paren`>should i try to reboot?
<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.
<vivien>flatpaks should work on guix
<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>And yeah, I use nix when something isn't packaged for guix
<gordon1>PotentialUser-18: found that thing
<gordon1>subscribe to updates
<PotentialUser-18>I've seen this in a bunch of places, but sadly it doesn't help at all really
<gordon1>right, as i thought
<gordon1>patchelf then
<rickame>tildetown, cool
<gordon1>PotentialUser-18: it isn't particularly hard to use tool and not so convoluted, i guess man patchelf is an ok start
<PotentialUser-18>Okay, thanks, Imma try spending more time learning patchelf then
<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 about ldd
<gordon1>which package contains ldd in guix?
<gordon1>i thought it's part of glibc
<nij->`guix search ldd`
<gordon1>actually it is in glibc, just not exposed in my path
<PotentialUser-18>`ls -l $(type ldd)` yields gcc-toolchain
<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
<xelxebar>Hey Guix!
<nij->o/ xelxebar
<nij->Anyone using `guix home` has run into the error "mkdir: Permission denied"? I saw a thread online but non of the solution there resolved the error..
<nij->I've also tried the methods here:
***the_tubular79 is now known as the_tubular
<the_tubular>No clue who exactly is maintaining this : but there's no new commits since a couple of days.
<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
<PotentialUser-18>And run just minimal configs
<PotentialUser-18>until it works
<nij->to me?
<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.
<xelxebar>nij-: What login manager are you using?
<nij->What's a login manager?
<nij->I have %base-service now.. I don't have a working wm yet.
<the_tubular>Something that shouldn't exist /s
<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.
<the_tubular>It's where you login with a GUI
<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?)
<PotentialUser-18>What is what?
<nij->=> /run/user/$(id -u)
<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 (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.
<Charles[m]1>btw dp0 it is
<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
<Gooberpatrol66>how can i view old guix pull news entries?
<raghavgururajan>Hello Guix!
<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: connection failed: No route to host
<raghavgururajan>That has been there for a week now.
***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
<raghavgururajan>apteryx: I see.
<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>hey Guixters !
<jeko>good morning
<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>lilyp: thank you !
<vivien>guile-3.0 is already 3.0.7
<vivien>Hello guix :)
<sneek>Welcome back tissevert :)
<tissevert>sneek: botsnack
<tissevert>hi guix
<jeko>Hi !
<user_oreloznog>hello guix!
<jeko>I can't find why my ynm-web can't (use-modules (ynm-core entities))
<jeko>anything obvious from the definitions ? :S
<jeko>I have 3 propagated inputs and the other 2 are importable
<tissevert>not sure what you mean
<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 ?
<jeko>tissevert: yep!
<tissevert>doesn't it provide a clean stacktrace with the exact location of the import ?
<jeko>(use-modules (spec)
<jeko> (dsv)
<jeko> (ynm-core use-cases))
<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
<jeko>same for guile-dsv…
<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
<jeko>ynm-core does not
<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>ok, from jeko-packages
<tissevert>makes sense
<tissevert>wait what ? isn't there a loop ?
<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
<jpoiret>ie `guix shell guile ynm-core`
<jeko>jpoiret: there I can (use-modules (ynm-core use-cases)) ! no errors
<jpoiret>yes, that's normal :)
<jeko>ok haha
<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
<tissevert>but then why did it work with guile-spec ?
<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>no ynm-core !
<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
<jeko>I appreciate :)
<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
<jpoiret>fiesh: that's
<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)'
<faus45>can any one help?
<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
<the_tubular>Ohh, mind sharing me the commit ?
<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>Umm, that's initial support.
<the_tubular>I've been using it for about a month
<the_tubular>It's still a bit wonky
<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)
<fiesh>ah hmm sorry
<the_tubular>It's getting there :)
<the_tubular>But it's still need a bit of work
<wigust>hi guix
<the_tubular>When would be the best time to unatended upgrade ?
<the_tubular>So that I can build the least amount of packages
<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
<hasjplante03[m]>does someone know how to fix record abi mismatches?
<hasjplante03[m]>can't reconfigure using guix system or guix home because of this
<lilyp>hasjplante03[m]: record abi mismatches should not occur in properly pulled guix
<lilyp>do you run guix from pre-inst-env?
<lilyp>if so make clean-go; make
<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
<hasjplante03[m]>lilyp no i do not run guix from pre-inst-env
<hasjplante03[m]>just ran a fresh guix pull
<hasjplante03[m]>it still happens
<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>no, this leads to a store directory
<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]>i deleted all of ~/.cache/guile/ccache/3.0-LE-8-4.5/
<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))`
<hasjplante03[m]>running it in the repl gives the same error
<jpoiret>i don't really know where it looks for compiled files
<jpoiret>%load-compiled-path should give you hints
<jpoiret>it's a guile variable
<hasjplante03[m]>seems like reinstalling is the only solution
<jpoiret>reinstalling what? guix?
<jpoiret>i don't think that's the proper course of action
<hasjplante03[m]>ill try running `guix gc`
<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
*gordon1 uses vim
<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!
<roptat>sneek, seen zimoun?
<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>same error :(
<csantosb`>Transactions avoid this kind of issues.
<cmack>csantosb`: Is this something implemented in guix that I need to enable explicitly?
<csantosb`>Not to my understanding.
<cmack>ah, is it a wishlist item?
<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
<jpoiret>are you on guix system or foreign?
<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
<cmack>guix system
<csantosb>cmack: Solved the problem ?
<Charles[m]1> says that it should be semi-colon separated, but cmake-build-system is using colon separated.
<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>current-guix not guix-profile sorry
<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>the package manager at first.
<drakonis>doing guix system requires more.
<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.
<drakonis>it is doable.
<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
<drakonis>guile already runs on macs
<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
<jpoiret>i mixed up the two
<cmack>ok trying
<cmack>same error
***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
<podiki[m]>ah, --expose=/etc/localtime
<cmack>drakonis: system rollback?
<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?
<gordon1>i'm experiencing that issue because i don't have %desktop-services in my system.scm
<gordon1>right, that's elogind
<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
<gordon1>yeah, figured it out already
<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)?
<ekaitz>eonn: short answer: yes
<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?
<drakonis>does it?
<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
<ekaitz>^ supplementary-groups
<gordon1>oh no, it's not about what my user belongs to, more like what is required for udev/mdev
<drakonis>disks isn't part of the default list
<drakonis>you can find it in gnu/system/shadow.scm
<drakonis>under %base-groups
<drakonis>also the group is disk, which i looked up incorrectly lol
<gordon1>yes, it's there
<drakonis>which is why i didn't find it while grep-ing the source
<drakonis>i looked for disks
<gordon1>thanks, so i guess i can just extend it
<drakonis>my bad.
<gordon1>in my system.scm
<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
<gordon1>at least with my default config
<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
<lfam>Ditto for webkitgtk
<Ribby>What does Guix stands for anyway?
<Ribby>*What does Guix stands for anyways?
<gordon1>something recursive
<drakonis>guile nix? or something like that?
<Ribby>It has the letter x. Must be, experience, excellence, excellency, extra, exciting?
<drakonis>does it matter?
<lfam>We can assume that it's a portmanteau of Guile and Nix
<drakonis>its very safe to assume that
<lfam>Although, the earliest code of what become Guix was called snix
<gordon1>GUIX Is Useful niX
<vagrantc>it also happens to be pronounced in french more or less like the english "geeks"
<gordon1>damn can't read
<drakonis>scheme nix?
<lfam>See the notes here:
<lfam>Yeah, I figure drakonis
<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
<lfam>Names are hard
<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>how does it brick your system again?
*eonn chuckles
<drakonis>cc is not available because of the gnu build system
<drakonis>ie: C compilers
<gordon1>drakonis: nuked grub.cfg
<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>*to bash
<gordon1>refreshed it now, should boot i home
<drakonis>post your config to
<drakonis>i want to see what you did here
<gordon1>1 sec
<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
<lfam>I'll find an example
<drakonis>i don't think so?
<lfam>eonn: Here's an example of what to do: <>
<gordon1>well, i'm guessing here, no idea what has happened
<drakonis>ah yes
<lfam>eonn: The only thing you'd need to change would be the filename in which to perform the substitution
<drakonis>don't actually mount /run/ as tmpfs
<drakonis>because it holds the current system inside
<gordon1>yes, that
<gordon1>not going to do that again
<gordon1>will put tmpfs to /run/user instead
<lfam>eonn: That cc-for-target procedure is a special abstraction that provides the right compiler in cases where the user is cross-compiling
<gordon1>but that was fun
<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
<drakonis>why mount tmpfs there?
<eonn>I'm packaging posix_ipc
<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
<drakonis>i see
<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