IRC channel logs

2022-09-28.log

back to list of logs

<pkill9>do gnome shell extensions need to be installed system wide?
<pkill9>guix has it's own emoji
<pkill9>hmm
<pkill9>guix has it's own emoji 🐮
<pkill9>well Gnu, guix's is a ribbon
<lechner>Hi, I'm in guix shell with a gnu-build-system. Should 'file' be pulled in? ./configure: line 6750: /usr/bin/file: No such file or directory
<jab>off topic question...has anyone tried to run guix system on the steam deck?
<drakonis>it would probably work
<nckx>lechner: Yes.
<nckx>/usr/bin/file, of course, less so.
<jab>drakonis: would you agree with me in saying that vavle has done a lot to improve the linux graphics ?
<jab>experience?
<drakonis>hmm, probably?
<drakonis>they have funded development on the area
<jab>drakonis: just curious. thanks
<drakonis>why are you asking?
<jab>drakonis: oh I just went down a "what hardware targets linux." And basically I feel like I owe vavle a rather heart felt thank you. just trying to make sure that was true...
<drakonis>valve, ya mean
<drakonis>but yeah.
<drakonis>valve's been paying people to work on mesa and vulkan iirc
<drakonis>plus wine
<apteryx>rekado: I wonder why kreuzberg is idle while overdrive1 is building stuff for hours?
***Xenguy_ is now known as Xenguy
<sleepy-dog5463>hi, i'm a new user with a new install, and i'm curious if anyone can point out where i had a misstep. After doing a `guix pull` and/or `guix package -u` it guix still notifies my that my packages are out of date... I think i may have updated with a misplaced `sudo` at one point. any tips appreciated.
<iyzsong>sleepy-dog5463: after `guix pull`, ~/.config/guix/current will point to the pulled latest. the current directory is in the PATH variable with a high priority, so `which guix` expected to return `~/.config/guix/current/bin`. if you pull with sudo, it updated root's guix, not the current user's.
<rekado>apteryx: no idea. Can all three of the machines be reached?
<rekado>apteryx: are they set up to be used? Is overdrive1 marked as faster, so it will get more jobs?
<unmatched-paren>hi guix :)
<mothacehe>hello!
<unmatched-paren>Hmm, savannah.gnu.org is returning 502 for me
<mothacehe>seems to be working here
<zimoun>mothacehe: issues with Savannah here.
<efraim>I'm also getting 502 from savannah, but prefixing with torsocks seems to work
<henk-utrect>hello guix-ers!
<henk-utrect>I have some problems with guix on Scientific linux, used as a package manager. I have many package definitions, every one mostly in their own file, and a couple of them refuse to load. Strangely, after editing one of the reluctant modules (mostly spaces or newlines), I can use guix build xxxxx once, after which it refuses to work.
<henk-utrect>I believe there is some caching going on somewhere, but I have removed .cache/guile/ccache many times to no avail. I there something else I could check?
<henk-utrect>Thanks for anyone willing to help!
***Dynom_ is now known as Guest4476
<minima>hi, i'm having this 'bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)' error since switching to guix home (on a foreign distro)
<minima>i noticed my $GUIX_LOCPATH is no longer defined, could that be the reason for the error?
<minima>and yes, glibc-locales is installed
<henk-utrect>minima I have my $GUIX_LOCPATH defined in .bashrc, that seems to work
<minima>henk-utrect: did you define that manually as a bashrc addendum so to speak or was it picked up by guix home automatically, as part of 'guix-defaults? #t'
<henk-utrect>minima I did it manually
<henk-utrect>I think that's necessary, but I don't think I use guix home, I'm just running guix on a foreign distro
<minima>yeah thanks henk-utrect - i also used to have it (manually added) but i thought that was going to be handled automatically by guix home
<henk-utrect>minima, sorry then, no experience with that :)
<minima>henk-utrect: hey no prob, thanks for getting back to me and sharing your thoughts!
<rekado>henk-utrect: what does “refuses to work” look like?
<henk-utrect>Hi, thanks for responding! Basically it warns 'guix buildL warning: failed to load '(ubc packages prokka)' (for in total 5 packages), and then (no surprise) guix build: error: prokka: unknown package
<henk-utrect>@rekado so weirdly earlier I could do a 'guix build prokka' which finished successfully once
<rekado>henk-utrect: for failures like this I recommend using “guix repl” and then load the modules manually to see if there are any relevant error messages that Guix might have helpfully swallowed…
<henk-utrect>rekado that is very helpful indeed, I loaded the file and it gave an error about another custom package
<henk-utrect>here I used dirname (current-filename), do you think that may be a wrong thing to do? the error mentions 'dirname #f'
<rekado>current-filename does indeed behave differently depending on whether the file is compiled or loaded
<rekado>in my experience it’s best to avoid it
<rekado>the alternative would be to use modules for everything and find them on the GUILE_LOAD_PATH
<henk-utrect>I'm starting to see that, thanks! Any pointers on how to refer to 'local files'? I've basically packed binary files in the base of my module git repo
<henk-utrect>for that I use the current-filename trick, probably that's doing me in
***PrinceMyshkin02 is now known as PrinceMyshkin0
<rekado>henk-utrect: in the Guix sources we use local-file (inside of G-expressions) and search-auxiliary-file.
<rekado>search-auxiliary-file is defined in (gnu packages) and by default it searches a file under /gnu/packages/aux-files
<rekado>but the parameter %auxiliary-files-path can be changed with (parameterize ((%auxiliary-files-path …)) …)
<henk-utrect>rekado  sounds like a plan, is there any way to 'automatically' find the location of the packages (just asking :) )
<webantipode>henk-utrect: Note that 'local-file' accepts relative file names (and will resolve them at compile time), no current-filename needed:
<webantipode>(local-file "local/file.tar")
<webantipode>henk-utrect: package-location finds the location of a package
***polo_ is now known as polo
<webantipode>scheme@(guix-user)> (package-location (specification->package "hello"))
<webantipode>$1 = #<<location> file: "gnu/packages/base.scm" line: 86 column: 2>
<webantipode>Or from the CLI: "guix show hello"
<henk-utrect>webantipode thanks, I'll give that a try!
<minima>on my second 'guix home reconfigure config.scm' i get a 'specifications->packages: unbound variable' error - but i do import 'gnu packages'... any idea on what i might be missing?
<minima>i'm trying with a guix pull/upgrade, to see if that helps
<webantipode>minima: Output of "guix describe"?
<webantipode>In particular, the 'commit: ...' and 'branch: ...' field.
***wielaard is now known as mjw
<minima>webantipode: branch: master and commit: 2e0fa826c9a7bbb159fb4fae38a7de10fe66d8bc
<webantipode>Commit and branch should be fine.
<minima>thanks webantipode
<henk-utrect>,q
<henk-utrect>sorry :)
<rekado>why does “guix build /gnu/store/1rgv9r4ska04c163960rmmvwiir7qjx0-guix-70a593242.drv” print a seemingly unending stream of “substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%” messages?
<rekado>it eventually does what it should, but I thought this was a thing of the past
<rekado>does derivation substitution not make use of pipelining?
<lechner>nckx: i found it. should libtool refer to the absolute /usr/bin/file ? https://paste.debian.net/plain/1255284
<webantipode>rekado: I noticed such things too.
<webantipode>minima: The only remaining potential issue I can think of: are you sure you imported (gnu packages) (before using it, and in the same module)?
<lechner>Hi, which path should I use to refer to programs in a hashbang in my personal scripts, please?
<rekado>lechner: the only thing you can be sure of is that /bin/sh exists
<webantipode>For 'personal scripts' not managed as Guix packages, I would say #!/usr/bin/env would be most convenient
<rekado>usr/bin/env is not necessarily available unless you linked it (e.g. with special-file-service)
<rekado>one common trick is to start with #!/bin/sh and then exec bash or whatever, relying on a lookup in PATH
<webantipode>rekado: Going by the existence of /usr/bin/env on my Guix Ststem, it is available by default.
<webantipode>lechner: ‘These files may be copied into source trees by libtoolize, therefore they must not be point to store file names’ (comments in libtool package definition)
<webantipode>Patching /usr/bin/file references is done automatically by gnu-build-system.
<rekado>webantipode: it is only created by special-files-service-type
<lechner>webantipode: Hi, it isn't patched inside my 'guix shell --development --file' ./configure: line 6750: /usr/bin/file: No such file or directory
<webantipode>rekado: special-files-service-type is added by default, see %base-services
<webantipode>lechner: Does it cause problems?
<webantipode>IIRC, I have seen it before, and 'configure' will just continue.
<lechner>rekado: Hi, should '/usr/bin/env' behave differently than 'env' in bash with $ type env pointing to env is /gnu/store/y1q29mchjs0ki8mznjw7lh42v6jh98w2-profile/bin/env
<webantipode>To solve things, see https://debbugs.gnu.org/cgi/bugreport.cgi?bug=17840
<lechner>webantipode: it continues
<rekado>webantipode: oh, in 2019 already!
<webantipode>Will send a mail to there, I think I can address at least some of the concerns
<lechner>webantipode: thanks for the bug reference! i have had that conversation a lot in other contexts. people get enamoured with absolute paths. they should all come to Guix!
<lechner>webantipode: meanwhile, do we not have a packaging way to substitute absolute path names?
<webantipode>webantipode: substitute*, but see: ‘‘These files may be copied into source trees by libtoolize, therefore they must not be point to store file names’ ’
<lechner>i though we provide some linked environment, if needed
<lechner>at build time
<webantipode>lechner: See: substitute*
<webantipode>(and the patch-usr-bin-file)
<webantipode>(Sending it will have to wait for a bit, can't connect to the SMTP server)
<minima>webantipode: my home-configuration.scm follows this pattern: https://paste.debian.net/1255290/ - which would look fine to me, but i must be doing something wrong somewhere
<webantipode>minima: Maybe you are importing some (non-Guix) modules that use specifications->package but you didn't import (gnu packages) in those modules
<minima>hm... good point, let me check that
<webantipode>Also, a useful trick for unclear things is to start with the original configuration, make a copy, then remove things+rerun the command until you found what's causing the issue
<minima>ok, so in terms of the non-guix modules, hm, i don't think i'm importing anything non-guix at the moment
***polo is now known as Guest6276
<minima>good point re re-starting from the original configuration, i'll try that
<minima>ty!
<apteryx>rekado: I don't know any of the answers yet, but we should have a look :-) perhaps the cuirass worker just need to be kicked
***normalmeo is now known as meonormativity
<ekaitz>rekado: someone told me you are looking for people for hacking in some shepherd stuff (ping me please)
***ryan9 is now known as ryan_t
<apteryx>btrfs-pool-ssd is now RAID1 instead of RAID10, so we'll be able to remove multiple drives from it
*apteryx runs 'btrfs device remove /dev/sda3 /dev/sdb3 /mnt/btrfs-pool-ssd'
*jonsger[m] has icedove 102 up and running :)
<gabber`>my super minimalistic C program (https://termbin.com/yymi) fails to compile (https://termbin.com/fyvp0) with a standard `gcc foo` call in a Guix shell (https://termbin.com/5227). am i missing some packages in my shell? i'd guess a simple `gcc-toolchain` in a shell should suffice to compile a simple "hello, world"-like program in C
<minima>regarding my 'guix home reconfigure config.scm' issue, i'm now seeing this error: 'no code for module (gnu home services ssh)'
<minima>do i need to make guix home aware of something? like i have the feeling this could be due to some missing path in my env?
<jpoiret>gabber`: does it work with only `guix shell gcc-toolchain -- gcc main.c`?
<jpoiret>gcc-toolchain already contains a glibc
<abrenon>hi guix
<gabber`>jpoiret: no, this also gives a huge bunch of error messages (altough they seem to be reordered from the last call)
<nckx>lechner: Yuck. I had no idea that it was a known bug, let alone so old.
<jpoiret>gabber`: you seem to have some includes in your home profile that are picked up by the guix shell
<minima>oh ok, i think i found what the problem is with my guix home - it's a missing 'export GUIX_PROFILE="${HOME}/.config/guix/current"' and 'source "${GUIX_PROFILE}/etc/profile"'
<abrenon>it seemed a good idea at the time but it wasn't this brilliant after all: I submitted a patch for a haskell package during the anniversary event in Paris
<abrenon>pasting the link here in case anyone has some time to look at it https://debbugs.gnu.org/cgi/bugreport.cgi?bug=57862
<minima>i had removed those from my '.bash_profile' as i had the impression the guix home bash service was going to take care of those - but i was wrong, those are actually needed as far i understand?
<gabber`>tho i'm not sure where the wicked packages/libraries in my home-config should be, a simple addition of `--pure` to my `guix shell` calll fixed the issue! jpoiret: any idea on how i can spot/identify the troublemaker?
<gabber`>and thanks!
<jpoiret>i've no idea, but it should most likely be a gcc-toolchain that you specified in the list you packages you want in your home profile
<abrenon>has anyone been advancing the CI pre-validation stuff ?
<abrenon>because I just got substitutes for that packages I've submitted a patch for
<jpoiret>yes! bordeaux serves the substitutes built by the QA service
<jpoiret>see https://qa.guix.gnu.org/
<abrenon>(that's so awesome 🤩)
<abrenon>I heard about it during the conference in Paris, but witnessing it first hand is yet another level
<gabber`>jpoiret: gcc-toolchain is not in my home profile... interestingly enough the newly built binary instantly raises a segfault -- when looking at it with gdb i see a different glibc libc.so.6 path than what i get when i `guix build glibc`.
<jpoiret>did you remove the glibc part of the manifest?
<gabber`>no -- should i?
<jpoiret>yes, the glibc is included in gcc-toolchain already
<jpoiret>you should also refer to gcc-toolchain's libc.so.6 to see if it's the right one
<gabber`>indeed, the one in `guix build gcc-toolchain` and the one referred to in my binary match.
<minima>so, this is what i used to have in my .bash_profile - and that i removed it but i understand it's actually needed (even after switching to guix home): https://paste.debian.net/1255307/
<minima>can anyone confirm whether this makes sense, if i'm right in thinking that that is needed and is not taken care by the guix home bash service automatically?
<gabber`>jpoiret: thanks again for your inputs! i was able to figure it all out!
<f3n1x>i want to create a 'guix shell' environment, like this 'guix shell --manifest ~/jekyllcodex-shell/jekyll-manifest.scm'. i'm getting an 'Missing required argument after `--manifest''
<f3n1x>shell error. What am i missing ? What's the apropriate syntax for ?
<gabber`>maybe you need a `=path/to/file.scm`?
<f3n1x>yay, it works now. Thanks, thanks, thanks
<gabber`>np, it works without the `=` in the short form (with `-m`)
<gabber`>it had me confused too
<f3n1x>well, i've used '--manifest=/my/path/foo-manifest.scm' succesffully
<civodul> https://guix.gnu.org/en/blog/2022/wrapping-up-ten-years-of-guix-in-paris/
<abrenon>yay !
<abrenon>also, o/ civodul
<abrenon>aaah soo many videos to watch, I don't know where to start
<ae_chep>abrenon: what videos?
<dthompson>civodul: definitely going to watch some of those videos. I was only able to catch a couple of sessions on the live stream. thanks!
<civodul>there's a lot of great stuff in there! :-)
<civodul>ae_chep: see https://10years.guix.gnu.org/program/
<abrenon>(there was a link in the original blog post)
<ae_chep>okay, I'll find it in there, thanks
<simfish>is it possible to install qemu-kvm using Guix on a foreign distro? Couldn't figure out which package to use.
<nckx>I'm not finding any results for qemu-kvm. How does it relate to qemu?
<unmatched-paren>is kvm support not included in qemu by default?
<nckx>I can't guarantee it from experience but Guix's QEMU packages *should* work on any distro. Setting up the appropriate permissions for /dev/kvm etc. are up to the user or the foreign distribution.
<nckx>unmatched-paren: Yes.
<nckx>There is no separate qemu-dog-slow package.
<nckx>Uh, anyway, got distracted: the package you're looking for is probably ‘qemu’, there is no separate usable version.
<simfish>Yep, got qemu. I thought vkm was a thing to install seprately. I should read the docs I know.
<simfish>thank you all
<nckx>It's monolithic and should give you access to all -system platforms
<nckx>For some reason, as soon as I unmaximise HexChat it stops rendering parts of its window (such as the current chat :), meaning I was babbling to you in a completely different channel.
<nckx>Has anyone else noticed that?
<nckx>Sway, if it matters.
<abrenon>'later
<bost>I'm trying to natively install guix using an iso image I created myself with `guix system image -t iso9660` and I get:
<bost> [... building and applying stuff ...]
<bost> initializing operating system under '/mnt'...
<bost> copying to '/mnt'...
<bost> populating '/mnt'...
<bost> error: failed to evaluate directive: (directory "/var/lock" 0 0 1023)
<bost> guix system: error: chmod: No such file or directory
<bost> Command ("guix" "system" "init" "--fallback" "/mnt/etc/config.scm" "/mnt") exited with value 1
<unmatched-paren>bost: please use a paste site
<bost> Press Enter to continue.
<bost>Does anybody know what's going on?
<unmatched-paren>like paste.debian.net
<bost>ups, sorry.
<unmatched-paren>it's fine, and sorry, i'm not srue
<unmatched-paren>sure
<bost>The error is here https://paste.debian.net/1255314/
<a12l>Has there been a recent comparison between Guix (System) and Nix(OS) written recently, and their different ecosystems? I'm a NixOS user, and have done some small contributions to Nixpkgs (added and changed some quite simple build functions). I'm mostly interested in the the programming languages and the "api"(?) to the package repository/library/everything (Nixpkgs in the Nix ecosystem).
<a12l>When I write Nix attributes and functions I feel that there's so much magic that happens in the background, and the lack of developer tools and documentation makes it hard to dig through how stuff works.
<a12l>I think my problem with the Nix ecosystem is that
<a12l>- it's hard to get mental models of how it fits together;
<a12l>- how to use the different functions available in Nixpkgs; and that
<a12l>- it's plain hard to read Nix code because it's not uncommon to have several different nested functions.
<a12l>I guess I'm looking for a Nix with better developer ergonomics, and wondering if Guix maybe is a better alternative for me.
<lechner>nckx: thanks, i added 2c in hope of some movement https://debbugs.gnu.org/cgi/bugreport.cgi?bug=17840#44
<yuu[m]>a12l: i had written some points on https://matrix.to/#/!jivGmMiiorFwdgwaxc:matrix.org?via=matrix.org&via=hummingbard.com&via=privacytools.io iirc here and on #nix:nixos.org as well.
<lechner>a12l: as a newbie to Guix I feel affected by some of the same things here. at the same time, i found the barriers here much lower. in fact, i never tried Nix
<yuu[m]>a12l: so language-wise guix is better from an user perspective. guix official package repo also more correct on trying to bootstrap the whole dependency tree instead of doing workarounds to get pre-built stuff.
<yuu[m]>a12l: guix documentation i find better greatly bc i can access it from emacs
<yuu[m]>a12l: nix flakes is closer to guix manifest than one would expect. still different though. no automation/lockfile in guix manifest for revisions and stuff while flakes has it
<bost>a12l: IMO Guix can be observed as Nix with better ergonomics if you consider Guix's system language (Guile Scheme - a Lisp dialect) to be better than Nix's system language.
<yuu[m]>a12l: language discovering is pretty bad in nix, not actually documented, ... the encouraged and documented approach to use the repl on guix/guile is a good thing, but you will find undocumented or poorly documented guix stuff as well
<bost>a12l: otherwise one may claim that e.g. lisp macros with all that quoting, unquoting, pseudo-quoting etc. is as hard to read as nested functions.
<yuu[m]>i mean guix DSL, that does not apply to guile
<bost>yuu[m]: my only problem with guile is the lack of examples. Something like https://clojuredocs.org/ would be really really great.
<yuu[m]>a12l: tbh i think in comparison the most notable issue is contributing to guix repo. they contributing patches to Guix repo is unflexible, slow, months from Guix reviewers
<yuu[m]>nix things are way faster
<yuu[m]>nixpkgs at least
<bost>yuu[m]: better said my biggest problem with Guile
<yuu[m]>bost: sourcegraph.com/search to the rescue
<yuu[m]>too bad it does not includes sr.ht, and codeberg...
<bost>yuu[m]: what is sr.ht and codeberg?
<unmatched-paren>bost: https://sourcehut.org https://codeberg.org
<yuu[m]>bost: i also cloned guix repo and look into it often, just like i do with nixpkgs
<unmatched-paren>they're both free alternatives to github/gitlab :)
<bost>unmatched-paren: thx
<unmatched-paren>(gitlab CE is free, but gitlab.com uses gitlab EE, which is nonfree and uses google tracking, and anyway they're both steaming piles of JS)
<unmatched-paren>bost: the former is a paid service, but it is AGPL3, so you can also self-host it, and I think it's worth it
<unmatched-paren>to pay, that is
<bost>yuu[m]: I also cloned the guix and guile repos and search in there. But what I really mean is the examples, like let's say how to create and access a hash-map. The little snippets as on the clojuredocs. (Let's see if I can find anything like that on codeberg, sourcehut or sourcegraph...)
<a12l>bost: Are Lisp macros pervasive in the ecosystem, or do people generally try to avoid more complicated stuff?
<a12l><yuu[m]> "a12l: tbh i think in comparison..." <- yuu: Thanks for your insights!
<bost>a12l: I'd say people tend to avoid to use them since they require more brain power to write and/or understand them.
<a12l>bost: Thanks, that sounds like a good habit!
<a12l>I'm quite tired of trying to mentally interpret Nix code that can depend on code in several different files in different parts of Nixpkgs.
<bost>a12l: but actually they are not _that_ difficult. Have a look here for example https://media.ccc.de/v/rc3-257534-all_programming_language_suck_just_build_your_own_language_oriented_programming_with_racket
<a12l>How's developing in Guile?
<unmatched-paren>a12l: The standard library is nice and extensive
<a12l>I don't have a nee-jerk reaction to the amount of parenthesizes at least (looked at Racket a few years ago)
<bost>a12l: interpreting Guile is not easier I guess.
<unmatched-paren>Usually you can find anything that's generally applicable in (ice-9 ...) and (srfi ...)
<yuu[m]>bost: so in contributing to guix reviewers can be lets say unfocused about the main thing. sometimes for the discussion spanning to much time one's left wondering what is the intention of all this. but it seems this is somewhat a culture gnu-land, as i've seen similar things in emacs development
<unmatched-paren>ah, yes, this reminds me:
<yuu[m]>a12l: oppsie meant to @ you instead
<unmatched-paren>a12l: sadly, reviews can take a *long* time because there aren't many reviewers
<bost>a12l: For me, developing in guile is a lot less flashy than say clojure. As I said I personally miss the examples.
<a12l>yuu: Is this generally when you change existing stuff, or is it also when you try to add new stuff?
<a12l>No Clojure experience, so at least I'll not be nostalgic :P
<yuu[m]>unmatched-paren: well that as well, but *unfocused* is what i wanted to bring attention to. maybe it is because of a lack of good processes
<bost>a12l: No clojure exp? Hmm. That's a miss.
<a12l>yuu: Is it easy to maintain your own derivations in your own repos and use them there before your stuff is merged into the main repo?
<unmatched-paren>a12l: In guix, we don't write derivations directly
<unmatched-paren>instead, we write <package> records
<unmatched-paren>which are compiled into derivations somewhere along the line
<a12l>unmatched-paren: Meant functions that build derivations
<a12l>You don't write derivations by hand either in Nix :)
<unmatched-paren>Sure.
<unmatched-paren>In Nix, though, don't you do something like `rustPackage { ... }'?
<a12l>bost: I'm generally in favor of statically typed languages.
<yuu[m]>a12l: well i never actually contributed to guix, mostly from looking at its pachtes mailing lists ... but i saw this both in people trying to contribute changes and new packages as well
<bost>a12l: Yes it is rather easy. Starting a couple of days ago I started to use mine https://github.com/Bost/guix-packages and I berate myself that I haven't started earlier with that.
<a12l>bost: Nice!
<a12l>I maintain some stuff in my own repos to enable me to test things out etc.
<a12l>unmatched-paren: Nix has the `derivation` function, that Nixpkgs has about >9000 different wrappers
<unmatched-paren>I see, so a derivation-making function for each build system?
<a12l>Kinda
<unmatched-paren>Well, in Guix, every package is written using the ``package'' macro
<unmatched-paren>like this: (define-public foobar (package (name "foobar") (version "1.2.3") (source ...) (build-system foobar-build-system) (home-page "...") (synopsis "...") (description "...") (license license:...)))
<bost>a12l: as unmatched-paren said the discussions and the merge effort takes time. So basically I source a particular module from that own repo of mine while waiting for a merge to the upstream and after the merge I just throw the module out of my own repo.
<unmatched-paren>the build-system is another record that contains a bunch of procedures for building/cross-building that kind of package
<unmatched-paren>and source contains a "file-like object", which is basically any object that corresponds to a store path
<a12l>unmatched-paren: That does look similar to a attribute set sent to a derivation wrapper function
***mark_ is now known as mjw
<unmatched-paren>so a package, a (source ...) (which fetches code from the internet), (local-file ...) (which fetches code from the filesystem), etc
<a12l>Nix (current) problem is that many wrappers differs in some small (or big) ways so generally can do some small stuff, but has to understand a lot of code to do some more advanced stuff.
<a12l>unmatched-paren: Yep
<unmatched-paren>Guix also implements an idea called "G-expressions", which are basically a way of designating code that is run at build time
<lechner>Hi, why does this package declaration fail to inherit either name or build-system from linux-pam, please? https://paste.debian.net/1255323
<unmatched-paren>inside a #~(...) gexp, you can use #$foo ungexp, which allows you to refer to things outside the gexp
<unmatched-paren>and if you refer to a file-like outside the gexp, it will be built and substituted for the equivalent store path
<a12l>unmatched-paren: UNPURE CODE?!?!?!?!
<bost>a12l: no static typing is probably one of the biggest downsides of Guile. And AFAICS no gradual-typing (like in Clojure) or typed-racket exist for Guile.
<unmatched-paren>a12l: nah, not files
<a12l>I'll need to look at them
<unmatched-paren>example: (computed-file "my-file" #~(call-with-output-file #$output (cute display "foobarbaz!\n" <>)))
<unmatched-paren>#$output is a special object that refers to the store path of the output
<yuu[m]>bost: i think for static typing for something like guile you'd need at least automatic type inreference. for the purposes of language like elisp, guix/guile, you need something to iterate faster on the repl
<a12l>bost: Static typing is quite uncommon with configuration languages :(
<unmatched-paren>this will create a file-like that builds to a file called /gnu/store/...-my-file containing "foobarbaz!\n"
<yuu[m]>inference*
<unmatched-paren>lechner: Add (name "linux-pam")
<lechner>unmatched-paren: what about the build-system?
<a12l>One of the nice parts with more detailed static types is that types works as documentation that's checked by the compiler
<unmatched-paren>It will inherit, but it won't bind ``name'' to ``name'' in the other fields
<unmatched-paren>lechner: I have no idea why that wouldn't inherit
<unmatched-paren>you're not referring to build-system anywhere...
<a12l>A little different question, how is the community (outside of you people here now having a friendly chat with me :)
<lechner>unmatched-paren: actually it does inherit, but for some reason autoreconf is not available
<unmatched-paren>lechner: Strange.
<unmatched-paren>Ahah
<yuu[m]>a12l: well if you think using nix make you odd, then guix is actually hipster
<lechner>unmatched-paren: https://paste.debian.net/1255324/
<unmatched-paren>Our linux-pam is downloaded from a tarball
<unmatched-paren>which will include pre-generated autoconf stuff
<lechner>yes
<lechner>i see
<unmatched-paren>Because yours comes directly from source, we need to generate them ourselves
<unmatched-paren>and autotools aren't included in the native-inputs by defaoult
<lechner>i need to modify-inputs, right?
<lechner>i know how to do that
<unmatched-paren>so just (native-inputs (modify-inputs (package-native-inputs linux-pam) (prepend autoconf)))
<unmatched-paren>yeah
<unmatched-paren>a12l: the awesome thing about guile/scheme is it allows writing seamless abstractions (such as that modify-inputs macro)
<lechner>although it would be prudent to regenerate them every time. debian started doing that a few years ago, too https://salsa.debian.org/debian/debhelper/-/blob/main/debhelper-compat-upgrade-checklist.pod#L223
<lechner>unmatched-paren: ^
<unmatched-paren>Yes, that's now encouraged
<lechner>unmatched-paren: thanks for the Guix fix!
<unmatched-paren>but we can't do that with linux-pam right now, because it would cause a mass rebuild
<lechner>unmatched-paren: i meant to enable it in gnu-build-system globally
<unmatched-paren>Ahh, right
<unmatched-paren>that would make a lot of sense, yes...
<unmatched-paren>But it would also mean adding more default dependencies
<lechner>unmatched-paren: i am only testing code requested by the linux pam maintainer, so we can keep the tarfiles
<lechner>unmatched-paren: "autoreconf: autopoint is needed because this package uses Gettext" but guix package --search=autopoint comes up empty
<unmatched-paren>lechner: autopoint is from gettext
<lechner>whoops
<rekado>the glamorous toolkit looks really nice as far as GUIs go
*rekado just saw Konrad’s short talk on a malleable GUI for Guix
<lechner>unmatched-paren: is there a conflicting definition of gettext in Guix? error: /lcl/lechner/guile-pam/git/linux-pam.scm:13:4: package `linux-pam@1.5.2-1.dc2f566' has an invalid input: ("_" #<procedure gettext (_ #:optional _ _)>)
<unmatched-paren>lechner: Ahh, it's because (gettext ...) is used for i18n
<unmatched-paren>The ``gettext'' package is bound to ``gnu-gettext''
<lechner>unmatched-paren: thank you! now i get autoreconf: failed to run aclocal: No such file or directory
<unmatched-paren>hmm
<unmatched-paren>Ahh, aclocal comes from automake
<unmatched-paren>you may also need libtool
<unmatched-paren>if another error appears
<lechner>unmatched-paren: thanks! i did need libtool but shouldn't this one come with autoconf error: possibly undefined macro: AC_SEARCH_LIBS
<unmatched-paren>maybe add m4?
<spacecadet[m]>hello, I'm getting an error - "invalid value %unset-marker% for field type 'name'" - when I try to reconfigure, there's no file or line number though, any way I can track down what's causing this?
<lechner>unmatched-paren: pkg-config did the trick
<unmatched-paren>aha
<unmatched-paren>spacecadet[m]: please show your code
<efraim>ugh have a bunch of patches to bump newsbeuter and now suddenly rav1e no longer builds
<spacecadet[m]>unmatched-paren: IM and guix are on two different machines right now, I can copy my code over so I can share but I'm just wondering if there's a verbosity flag I can enable, I'm comfortable trying to fix the actual issue myself for now
<unmatched-paren>nope, sorry, guile has suboptimal debugging as is which is exacerbated by the strata in guix
<spacecadet[m]>gah
<unmatched-paren>hmm, anyone here done a service before?
<podiki[m]>a system level one? I just wrote one for peroxide (protonmail bridge) that I need to submit, but it works
<unmatched-paren>i want to figure out why my service is exiting as soon as it starts
<unmatched-paren>but the #:log-file is empty
<unmatched-paren>even though the process does print to stdout when i run it
<podiki[m]>I don't know that log-file automatically redirects from stdout
<podiki[m]>maybe explicitly capture output in what you run? (I haven't done anything with log-file option)
<a12l>unmatched-paren, yuu, bost, lechner: Thanks for the nice chat before!
<a12l>I think that I'll need to try to do some Guix development and see if it feels better.
<unmatched-paren>a12l: no problem! Re community: this and the mailing lists basically are the community
<unmatched-paren>there's not much of it :)
<unmatched-paren>there is an r/guix on reddit but it's unofficial
<unmatched-paren>and probably not the best place to get help
<a12l>unmatched-paren: But there aren't many fights or bad blood etc.?
<unmatched-paren>No, no, why would there be?
<a12l>Maybe hard to discuss here openly in an official channel :P
<a12l>unmatched-paren: I assumed not, but I know how Debian can be
<unmatched-paren>there are incidents now and then of course
<tricon>a12l: it's incredibly rare to see someone reprimanded, and the one time i witnessed it, the person was being petulant and rude.
<unmatched-paren>but no in-fighting or anything...
*unmatched-paren looks up "petulant"
<a12l>Nice to hear!
<unmatched-paren>ah, just a fancy word for a rude or easily angered person
*unmatched-paren is a native english speaker but has never heard that one before :)
<tricon>unmatched-paren: this is a perfect opportunity to tell you that your nick is wonderful and it haunts me.
<unmatched-paren>tricon: haha, thanks :)
<unmatched-paren>it's a wee bit long though.
<joanisc[m]>Hello guix community! Are you using guix as your main distribution or is actually in kind of Beta?
<podiki[m]>I think you'll find plenty here that use it as their daily driver (I do on one computer, my laptop does have guix as an additional package manger)
<podiki[m]>and I would on my laptop but it is older and set in its ways, so I don't have the heart to re-install everything
<unmatched-paren>joanisc[m]: hi! I use it as a daily driver, though it can be rather unstable at times
<unmatched-paren>i wouldn't recommend it to anyone who wants something completely seamless and user-friendly right now, as there can be incidents where the master branch is broken accidentally
<podiki[m]>I think it depends on what you want and use, certainly appeals to the tinkereres
<a12l>Does Guix has something comparable to NixOS's module system?
<lilyp>I use Guix as a daily driver exactly because it's resilient even with master broken.
<podiki[m]>but I haven't had any major breakage that I can think of
<lilyp>Imagine doing the shit we're doing on Arch.
<podiki[m]>yes, when I run into problems on Arch (which is rare) I miss the power of Guix
<podiki[m]>sometimes I don't update for a while on Arch or reboot for a while, so when I do I can't tell what went wrong, while with Guix you can easily go back
<podiki[m]>but it is probably a better fit for those that want to learn and tinker more (not required, but is certainly the fun of it too)
<unmatched-paren>podiki[m]: Do you know how I can figure out which (requirement '(...)) symbols i need to list?
<tricon>i just replaced Arch on my laptop with Guix last week. i use it as a daily driver at work for my workstation, and have a few Guix servers deployed. it runs great. no complaints.
<podiki[m]>unmatched-paren: for the service? no, I wasn't sure either, I was modeling after a similar service (so I wanted networking at least since it needs network access)
<podiki[m]>I guess you could explore the service dependency tree?
<apteryx>python-minimal is bigger on disk than python ^^'
<civodul>apteryx: "guix size" says i's a bit smaller: 148M vs. 155M
<podiki[m]>...how?
<yuu[m]>a12l: if you are on nixos you can try https://github.com/foo-dogsquared/nix-overlay-guix
<unmatched-paren>a12l: We use Guile modules
<unmatched-paren>so (define-module (...) ...)
<podiki[m]>and then install nix on guix on nix??
<unmatched-paren>packages aren't namespaced, so we have e.g. rust-foobar instead of rust.pkgs.foobar or whatever nix has
<unmatched-paren>Oh, huh, the service is running :D
<unmatched-paren>I guess I had to restart...
*unmatched-paren gonna see if it shows a battery notification
<unmatched-paren>I'll hopefully be able to drop the ad-hoc janet script i use for power notifications after this
<drakonis>you can have namespaces if you want though
<drakonis>but it definitely works differently from how it functions on nix
<unmatched-paren>Well for one thing ``guix install foobar'' doesn't refer to the variable ``foobar''
<unmatched-paren>it instead looks for a package with the name string ``foobar''
<unmatched-paren>so the variable binding could be something completely different
<unmatched-paren>e.g. for gettext, the variable is ``gnu-gettext'' to avoid conflicting with localization routines
<rekado>unmatched-paren: Nix Modules are something else; they are about building a system configuration. I think the best match in the Guix world are system services, which I consider to be a more elegant approach.
<unmatched-paren>Ahh
<unmatched-paren>I see.
<unmatched-paren>Yes, we also have home-services baked in, so no external home-manager project
<unmatched-paren>and ``guix home'' doesn't take over your entire /home ;)
<unmatched-paren>Hmph, batsignal isn't showing a critical message for 5%...
<antipode>a12l: Guile, the programming language used by Guix, has a module system (see 'define-module' and 'use-modules' in the Guile documentation)
<antipode>Nevermind, already answered.
<acrow>M-x guix-repl -> "No prompt found!" Hmmmmmm...... am I the only one who gets this?
<acrow>This is from emacs
<rekado>I don’t even have a guix-repl command, though I do have emacs-guix
<acrow>Well, this started by trying to use emacs-guix 'guix-edit'
<rekado>oh, there it is: M-x guix-version —> long wait time starting Geiser, and then “No prompt found!”
<acrow>Same result
<rekado>so, no: it’s not just you.
<rekado>the guix geiser repl did start, though
<acrow>Thank you. I hate when it is just me.
<acrow>Yes, from the shell I can successfully run 'guix repl'. I can also start geiser.
<rekado>civodul: I noticed that call-with-file-lock doesn’t clean up after itself: https://issues.guix.gnu.org/57501 – Should the lock file be deleted?
<rekado>civodul: I’m asking you because git log --grep=call-with-file-lock only shows your commits. Sorry!
<acrow>Yes, but 'guix-edit' fails. I can never remember where the current guix git repo is lodged and so I've become dependent on that emacs guix-edit crutch.
<acrow>That's the problem with reliance on higher level tools; they will embarrass you by failing at awkward moments.
<rekado>zimoun: IIRC you mentored for the wip-guix-log branch/project. Is this project still ongoing, or would it be okay to work on this?
<apteryx>unmatched-paren: you can use the beep job given as an mcron job example ;-)
<unmatched-paren>apteryx: thanks. looks like my problem is that the notifications aren't getting sent through...
<unmatched-paren>which seems to be because it's running as root
<unmatched-paren>but i can't do a home-service because then i couldn't use ``halt'' as the ``danger-command''
<jpoiret>that 10 years "Error in finalization thread: Success" picture is great
<civodul>isn't it? :-)
<jpoiret>can't wait for all the bug reports to be tagged WONTFIX
<podiki[m]>if we one day get rid/change that message, it should still be a hidden option or in a special logo for the old time guix users :)
<zimoun>rekado: the project is not ongoing. It requires some re-work to be merged. Do you have ideas for improvements?
<rekado>zimoun: nothing concrete; but today I gave a little Guix intro and the question came up again how to find the Guix commit that provides a certain version of a package.
<rekado>getting a clone of the repo and runnig “git log --grep” is a little too inconvenient
<jpoiret>magit-blame in emacs is pretty useful :p
<jpoiret>you can always consult the git repo in the checkout directory
<jpoiret>although that's not where `guix edit` will lead you unfortunately
<apteryx>hm, I'm getting "error: all-system-tests: unbound variable" when attempting to run make check-system TESTS=basic, although 'make' do not report any error; any clue?
<rekado>I’m talking about Guix users, not Emacs users ;)
<apteryx>this only occur with a change installed, so it has to do with it, but the lack of compilation warning/better error leaves me clueless
<podiki[m]>that sounds like a nice thing to hack to guix, so that guix will take git grep commands to the local current cached repo...?
<jpoiret>i think that'd be a bit too hard to implement
<rekado> https://git.savannah.gnu.org/cgit/guix.git/log/?h=wip-guix-log
<zimoun>rekado: I am working implementing an extensions using Xapian for that. Hence my recent questions about extensions. ;-)
<rekado>ah!
<rekado>zimoun: more power to you then!
<jpoiret>ah, using grep on the log! i completely forgot about the obvious pros of the ChangeLog format :)
<zimoun>’guix git log’ is nice but one needs some habits with ChangeLog format.
<zimoun>Well, do not hold your breath. :-)
<Gooberpatrol66>I tried hibernating my laptop and the screen turned off and the fan spun up to full blast and it's been like that for an hour and now I'm not sure what I should do
<jab>podiki[m]: what causes the "error in finialition thread: success" message ?
<podiki[m]>jab: I have no idea, it is the first mystery of guix I learned to ignore
<civodul>jab: something about fork/exec shenanigans during the early boot process
<civodul>i think jpoiret has a precise understanding of that :-)
<jab>podiki[m]: and civodul just curious. It's a pretty harmless warning message.
<jpoiret>just checked it out again
<jpoiret>basically, the Guile finalizer can run in its own thread, the finalizer thread, and communicates with the main program with a pipe that tells it when to run finalizers
<jpoiret>but the boot g-expression used to start shepherd basically closes all file descriptors and then execs (no fork involved), so when the fd is closed, the finalizer thread isn't prepared to handle that: it was waiting for info with a read on the pipe, but read 0 bytes (without any error, the pipe just closed!).
<jpoiret>the corresponding code considers that if you read 0 or less bytes, it should be an error, and so prints "error in finalization thread" + strerror(errno) but errno is set to 0 since the read succeeded :)
<jab>jpoiret: thanks!
<civodul>jpoiret: ah excellent! i guessed it was due to one of those FD-closing loops, but i didn't find which one
<jpoiret>tbh, the code should only check for errno != 0, not for read_bytes <= 0
<civodul>or data.n < 0
<civodul>(instead of <=)
<jpoiret>right
<apteryx>sounds like a simple fix!
<jpoiret>i always forget that -1 is error and that you should check out errno in that case
<civodul>"if (data.n == 0) return NULL" i guess
<nckx>lechner: Thanks, sent PM.
<nckx>Good wonderfully pleasant evening, Guix!
<jpoiret>i can send a patch for that, if we're okay with losing this much beloved warning message
*nckx is discovering https://qa.guix.gnu.org/
<jpoiret>or maybe civodul is already on it
<civodul>heh i was looking into it
<civodul>but then wondering whether that'd leave finalization_thread_is_running to 1
<civodul>which doesn't matter much if you're going to exec right after
<civodul>but isn't great otherwise
<jpoiret>closing random FDs is already UB I think
<nckx>Gooberpatrol66: Is this a ThinkPad by any chance? (Maybe even 3rd-gen Intel or thereabouts?)
<Gooberpatrol66>nckx: it's a framework
<jpoiret>or, we could just disable the finalization thread before closing the fds in Guix
<nckx>(That makes it sound like I have an explanation; I don't, just the same experience.) And ah. Not the same at all then.
<a12l>yuu: That overlay looks nice! I'll have to take a look at it :)
<jpoiret>nckx: oh no. Now it's 504'ing
<nckx>jpoiret: I DID NOTHING
<jpoiret>poor qa wasn't ready for the outside world
<nckx>It was already 504ing before I slashdotted it tho'.
<jpoiret>ouch
<nckx>I was on my 3rd attempt when I posted the above.
<apteryx>next pesky warning to get rid of: "Error: Driver 'pcspkr' is already registered, aborting..."
<civodul>jpoiret: yes, shepherd used to do that, but that requires poking with C to call scm_set_automatic_finalization_enabled
<apteryx>oh, it's even an error!
<civodul>which one cannot do without the FFI
<jpoiret>oh, and there's no ffi in the minimal guile?
<podiki[m]>the error in finalization thread, however it is eventually handled, should get a blog post, always fun to read about idiosyncrasies like that
<podiki[m]>apteryx: I've seen that one a lot, i think I removed that module since it bugged me
<podiki[m]>kernel argument "modprobe.blacklist=pcspkr,snd_pcsp" I think gets rid of it, but haven't checked recently
<nckx>Gooberpatrol66: Anyway, I don't think the two are directly related. My laptop does the fan thing too, but still hibernates. Is the system still running underneath the black screen? Could you SSH in, for example?
<nckx>podiki[m]: It deserves an official good-bye, yes.
<nckx>It's iconic.
<apteryx>perhaps a t-shirt
<Gooberpatrol66>nckx: it's not responding to pings
<podiki[m]>maybe not the icon we deserved, but the one we got
<podiki[m]>I like the t-shirt idea, and a sticker
<nckx>Gooberpatrol66: It seems like Guix kernels have CONFIG_PM_DEBUG on by default, which means you could try echoing test_resume to /sys/power/disk to do a fake hibernation that will hopefully wake back up, possibly printing something useful to dmesg.
<nckx>I think there's another knob…
<nckx> https://www.kernel.org/doc/Documentation/power/basic-pm-debugging.rst
<apteryx>nckx: indeed, per zgrep CONFIG_PM_DEBUG /proc/config.gz
<nckx>Chances of this successfully reporting an error aren't great, but I can't think of anything else.
<Gooberpatrol66>nckx: i will take a look, thanks
*nckx refuses to acknowledge that monstrosity. You mean grep /run/current-system/kernel/.config.
<apteryx>eh
<nckx>I wish we could symlink it from /proc.
<nckx>apteryx: I was kidding, mostly.
<nckx>But loading gzipped data into kernel memory just so it can be zcatted from user space… having it as a regular file still reliably linked to the running kernel was one of the things Guix did very right.
<nckx>But I guess it got enabled anyway.
*nckx shrugs.
<Gooberpatrol66>i was going to ask for it to be enabled because i didn't know the other file existed
<apteryx>eh, I was the one enabling it because I find it useful, mostly out of habit I guess.
<nckx>Isn't it?
<nckx>Ah.
<nckx>Too slow.
<apteryx>du /proc/config.gz reports 0! it's free! ;-)
*nckx counts to ten, thinks of pretty flowers.
<nckx>apteryx: I wasn't as serious as it sounded, sorry for the noise.
<nckx>I need to go outside and yell at a cloud or something.
<itd_>Hi. Is there a reason to prepend the package module search path to the package file location for non-guix packages? E.g., why is there a ./ in front of myhello-module.scm in https://paste.debian.net/plainh/9e53fe1b ? Thanks!
<nckx>Eyy, qa. loaded! But it's mostly ‘Comparison unavailable’. Still. Looking nice.
<nckx>itd_: Is it not helpful?
<nckx>That seems to be the ‘obvious’ reason.
<gabber>is it possible to patch generic udev rules (those which contain "/bin/" references to executables) in a guix system config file -- the way we substitute* and (which "foo") in package definitions? or is this solely done on a package basis?
***ec_ is now known as ec
<nckx>Is anyone already using qa.guix.gnu.org and/or patches.guix-patches.cbai nes.net as part of their workflow?
*jonsger[m] pushed icedove@102. Have fun and reports bugs if they do exist :)
<itd_>nckx: Sometimes. It seems the package file location is also used somewhere in the guix json importer to guess module names of packages. This doesn't seem to work that well with the added load path as prefix. (At least that's my limited understanding.)
<jab>podiki[m]: +1 for the t-shirt idea
<podiki[m]>credit to apteryx :) but 2 sales already!