<pkill9>do gnome shell extensions need to be installed system wide? <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? <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 ? <drakonis>they have funded development on the area <jab>drakonis: just curious. thanks <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's been paying people to work on mesa and vulkan iirc <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? <zimoun>mothacehe: issues with Savannah here. <efraim>I'm also getting 502 from savannah, but prefixing with torsocks seems to work <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? ***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>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 <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>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> <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>In particular, the 'commit: ...' and 'branch: ...' field. ***wielaard is now known as mjw
<minima>webantipode: branch: master and commit: 2e0fa826c9a7bbb159fb4fae38a7de10fe66d8bc <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? <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>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 <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 <webantipode>(Sending it will have to wait for a bit, can't connect to the SMTP server) <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 <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 :) <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 <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 <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? <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 <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? <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>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`) <f3n1x>well, i've used '--manifest=/my/path/foo-manifest.scm' succesffully <abrenon>aaah soo many videos to watch, I don't know where to start <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! :-) <abrenon>(there was a link in the original blog post) <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? <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>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. <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? <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> 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 <bost> Press Enter to continue. <bost>Does anybody know what's going on? <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>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 <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 <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? <yuu[m]>bost: i also cloned guix repo and look into it often, just like i do with nixpkgs <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 <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. <a12l>How's developing in Guile? <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 <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? <a12l>unmatched-paren: Meant functions that build derivations <a12l>You don't write derivations by hand either in Nix :) <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 <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>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. <unmatched-paren>Guix also implements an idea called "G-expressions", which are basically a way of designating code that is run at build time <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. <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" <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 <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 <yuu[m]>a12l: well if you think using nix make you odd, then guix is actually hipster <unmatched-paren>Because yours comes directly from source, we need to generate them ourselves <unmatched-paren>so just (native-inputs (modify-inputs (package-native-inputs linux-pam) (prepend autoconf))) <unmatched-paren>a12l: the awesome thing about guile/scheme is it allows writing seamless abstractions (such as that modify-inputs macro) <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 <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 <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 _ _)>) <lechner>unmatched-paren: thank you! now i get autoreconf: failed to run aclocal: No such file or directory <lechner>unmatched-paren: thanks! i did need libtool but shouldn't this one come with autoconf error: possibly undefined macro: AC_SEARCH_LIBS <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 <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 <podiki[m]>a system level one? I just wrote one for peroxide (protonmail bridge) that I need to submit, but it works <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 <a12l>unmatched-paren: But there aren't many fights or bad blood etc.? <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 <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 looks up "petulant" *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. <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 <unmatched-paren>packages aren't namespaced, so we have e.g. rust-foobar instead of rust.pkgs.foobar or whatever nix has *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>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>Yes, we also have home-services baked in, so no external home-manager project <antipode>a12l: Guile, the programming language used by Guix, has a module system (see 'define-module' and 'use-modules' in the Guile documentation) <acrow>M-x guix-repl -> "No prompt found!" Hmmmmmm...... am I the only one who gets this? <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!ā <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ā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>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 <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 <zimoun>rekado: I am working implementing an extensions using Xapian for that. Hence my recent questions about extensions. ;-) <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>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 :) <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 <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 <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 <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?) <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>poor qa wasn't ready for the outside world <nckx>It was already 504ing before I slashdotted it tho'. <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 <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. <podiki[m]>maybe not the icon we deserved, but the one we got <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ā¦ <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. *nckx refuses to acknowledge that monstrosity. You mean grep /run/current-system/kernel/.config. <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. <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. <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