IRC channel logs

<nckx>rekado: Well, you are the non-nonrekado channel I was referring to.

<jgart[m]>Has anyone gotten corfu completion to work with geiser?

<nckx>rekado: 3 ARM nodes seems worth it.

<nckx>ACTION -> zzz

<omlet[m]><omlet[m]> "Audacity without tracker right?" <- ?

<rekado>the new overdrive node doesn’t talk to berlin; is the cuirass-remote-worker service running?

<Michal_Atlas[m]>Is there a nice way to set the GCC version while writing a package with cmake-build-system?

<csepp>Michal_Atlas[m]: without looking at the docs, maybe the with-c-toolchain transformation? but i think cmake accepts a #:gcc field in its arguments?

<Michal_Atlas[m]>It seems to only accept #:cmake and with-c-toolchain crashes on me for some reason. Maybe I could swap it out in the cmake package 🤔

<csepp>how are you calling with-c-toolchain?

<csepp>on the CLI it should be as easy as: guix build --with-c-toolchain=dfc=clang-toolchain dfc

<csepp>replace clang-toolchain with gcc-toolchain@1.2.3, where 1.2.3 is the version you want (can be a partial version, like 1.2, or 1)

<Michal_Atlas[m]>Oh, that worked perfectly, thank you very much.

<Michal_Atlas[m]>Seems I didn't nail what the scheme version expected

<apteryx>hm. I was expecting share/info/TheLinuxKernel.info.gz manual installed along the kernel to be discoverable by a user. Seems it's not.

<apteryx>(e.g., to be able to simply 'info TheLinuxKernel' as my own user without having ot install linux-libre in my user profile)

<oriansj>to be honest, very little is discoverable in Guix unless one looks at the source code and can read scheme proficiently

<oriansj>doing grep -iR in ~/.cache/guix is the only information I can seem to find related to my questions about iwd and then having to do a guix reconfigure and hoping that it fixed the problem

<oriansj>and does anyone know a method of copying .cache/guix between users to reduce the number of times one needs to download all of guix

<apteryx>I think you can simply copy it, adjusting permissions for the user

<apteryx>haven't tried it though

<oriansj>tried that; no dice

<oriansj>as doing guix pull at 28KB/s is very painful

<jgart[m]>Has anyone configured lispy for guile development?

<jgart[m]>It seems to be hard set to execute racket but I don't see what defcustom to setq

<whereiseveryone>let me check ambrevar's dots...

<oriansj>woo, extra fun; guix version 3cff7bfa9b46f1b73381df79a6f2aaa55a332126 thinks the config built using 1.3.0rc2-1.566982b is invalid as I guess the syntax around static IP addresses changed...

<oriansj>and it looks like the new syntax isn't backwards compatible; which means one would have to update the guix on their install /mnt to use the newer guix to have a single standard config file

<jgart[m]> https://github.com/abo-abo/lispy/issues/640

<lechner>oriansj / hi, i have some equipment with static IPs. was the change documented anywhere?

<euandreh>Is there a way to include a custom guile module in a Guix channel?

<oat>Successful Manual installation [CSM & UEFI] Guix 1.3.0 on Toshiba Satellite C40D-A https://debbugs.gnu.org/cgi/bugreport.cgi?bug=59467

<oat>Does anyone know the advantage of installing UEFI vs CSM?

<lechner>euandreh / Hi, if it's just for use by applications i think the first step is to package it, and the second would be to make it available in your custom channel

<euandreh>lechner: I already have it packaged

<euandreh>It is a WIP scheme module that adds heredoc syntax to strings

<euandreh>And I wanted to write some documentation strings in my channel

<euandreh>So I want to use an extra Guile module in the code of my channel

<lechner>euandreh / is that an extra Guile module in Guix?

<euandreh>It isn't

<lechner>what did you mean by "write some doc strings in my channel" please?

<euandreh>I want to move this [0] to here [1]

<euandreh>0: https://euandre.org/git/servers/tree/src/infrastructure/guix/system.scm?id=d6a6e9fdc0c14555337a5dfb44c33386741699b0#n1241

<euandreh>1: https://euandre.org/git/package-repository/tree/src/xyz/euandreh/queue.scm?id=aadc288841efc1d969d89737141c925f928d4bff

<lechner>sneek / later tell oat / I believe CSM allows you to boot from disks partitioned with fdisk while some modern EFI implementation require GPT (gdisk). either way, GPT is far superior with respect to disk size. it also keeps a backup elsewhere on the dist

<sneek>Okay.

<euandreh>lechner: The #"...."# syntax comes from the (xyz euandreh heredoc) module

<lechner>euandreh / what happens if you move the string?

<euandreh>If I want to "guix pull" from the channel available at euandre.org/git/package-repository, Guix will break, because it doesn't know about (xyz euandreh heredoc)

<lechner>oat / please feed sneek

<euandreh>And it says something like "unknown reader object #\"..."

<lechner>euandreh / i am not sure. maybe you need two channels, and build guix before adding the second?

<oat>ardon: What do you want to say about signing digitally?

<sneek>oat, you have 1 message!

<sneek>oat, lechner says: / I believe CSM allows you to boot from disks partitioned with fdisk while some modern EFI implementation require GPT (gdisk). either way, GPT is far superior with respect to disk size. it also keeps a backup elsewhere on the dist

<euandreh>lechner: I believe the issue isn't about ordering or depedency, as I am already able to install guile-heredoc locally on my system.

<euandreh>The thing is: when Guix is pulling from a channel, how can I tell it: hey, before pulling, load this module

<euandreh>wait, guix pull accepts a -L option?

<euandreh>hmmmm, it does, I bet this is what I am after

<apteryx>pro tip: do not use exec* in your mcron jobs if you want to see the annotated exit status

<oriansj>lechner: not anywhere that I can see. So it is either guix system reconfigure input validation is off the reservation or the syntax had changed between those 2 versions. I have no idea of which

<oat>Hello rekado: How many times have you used Guix?

<oriansj>in related news I finally figured out how to get iwd to work (still has rough edges but): I needed to add the following under services: (dbus-service) and (simple-service 'iwd-dbus dbus-root-service-type (list iwd))

<oriansj>and then I manually had root run: /gnu/store/crdv76dqr7vdhicikqdf1896xhhq2d43-profile/libexec/iwd (I still need to figure out how to make that a shepherd service so I can stop manually starting it)

<oriansj>and just adding only those 2 lines magically broken DNS lookups??

<lechner>oriansj / what are the contents of your /etc/resolv.conf, please?

<oat>rekado: years*

<oriansj>lechner: echo -e "domain lan\nsearch lan\nnameserver 192.168.10.1"

<oriansj>issue seems related to the tor service (not sure how yet) as when it is stopped and the networking ervice restarted; dns looksup works again

<oat>sneek: lechner: for your answer. I wanted to talk about the performance. Is CSM faster than UEFI?

<oat>I found the graphics performance was better on UEFI but I would like to know the internals. Greetings

<oat>lechner: sneek Thank you in advance

<oriansj>and for those curious on how to get iwd mostly working on guix: my config should be educational: https://git.sr.ht/~oriansj/System_setup/tree/main/item/files/guix-config.scm

<oriansj>(this has been very educational if not a bit painful)

<lechner>oriansj / do you have a DNS resolver running on 192.168.10.1? there are benefits to local resolution, but in a pinch you could add a line reading "nameserver 8.8.8.8"

<lechner>oat / i believe that CSM is an implementation-specific BIOS emulation mode. none of my equipment has it. i find it hard to believe that graphics equipment runs more slowly under X or Wayland because Linux does not rely on the emulated layer, but anything is possible. for example, CSM could limit the number of interrupts and force some Linux drivers into polling

<oat>oriansj: Thanks for sharing. It's actually a useful file, congratulations.

<oat>lechner: Something happens when I install from the CSM the resolution was lower than UEFI. It's possible that BIOS enables something in the graphics hardware.

<lechner>oat / which card?

<oat>lechner: Radeon HD 8330

<lechner>oat / maybe the CSM layer causes the card to advertise lower capabilities, which then causes a misidentification in X/mesa/Wayland. you could check the logs. the CSM may also alter your northbridge configuration or bus speed, which is something our graphics software might not detect. all of that can be investigated, but i think you are better off going with UEFI

<oat>lechner: Thank you (Gracias)

<lechner>oat / de nada, compadre!

<unmatched-paren>podiki[m]: but since they're not exported, there's no substitutes for them :/

<jackhill>sneek: later tell jgart[m] I've at least updated my janet patches (built, but functionality not tested) to current Guix. Next up, packaging jpm and then the build system: https://git.hcoop.net/jackhill/guix/guix.git/log/refs/heads/wip-janet-2022

<sneek>Will do.

<unmatched-paren> https://issues.guix.gnu.org/59670 <- finally finished updating and fixing the build of zoxide :)

<unmatched-paren>why hasn't the ci built webkitgtk-with-libsoup yet?

<unmatched-paren>huh, looks like it has

<unmatched-paren>but it's still building locally for me...

<civodul>Hello Guix!

<reyman>@zamfofex Yes but i don't have the possibility to modify the way V8 manage the chromium compilation, this is specific to this package.

<reyman>i don't try to interfere with it, just trying to set the good option

<reyman>Actually V8 compilation of chromium failed with ./gen-regexp-special-case: error while loading shared libraries: libgcc_s.so.1: cannot open shared object file: No such file or directory

<reyman>this is strange because i have this :

<reyman> (inputs (list (list gcc "lib") glibc clang-toolchain lld glib python-wrapper perl))

<reyman>(native-inputs (list linux-libre-headers ninja gn ccache python pkg-config python-pkgconfig))

<civodul>reyman: gcc:lib and linux-libre-headers are part of the implicit inputs when you use 'gnu-build-system', 'cmake-build-system', etc.

<civodul>same for glibc

<civodul>also, instead of clang-toolchain, i think you need just 'clang'

<civodul>yeah for example qttools has just 'clang', not 'clang-toolchain'

<civodul>that's enough because the rest is already provided

<reyman>if i put only clang, the compile failed at some point, don't know why.

<reyman>actually i use cargo build system

<reyman>and then during the build, rust need to build v8/chromium

<reyman>so compilation are imbricated

<reyman>build is made by Rust using Ninja and Gn

<reyman>yeah this is weird..

<reyman> https://github.com/denoland/rusty_v8#build-v8-from-source

<civodul>oh, not sure what happens with cargo-build-system

<reyman>I push the channel with dependency for v8 core here : https://git.sr.ht/~reyman/rust-channel/tree , the main rust-v8-0-49.scm script is here : https://gist.github.com/reyman/84fa04ac1dee3efe26b8ab8c3434ffa3

<reyman>the command to run both : guix time-machine -C channels.scm -- build -f rust-v8-0-49.scm

<cbaines>data.guix.gnu.org might be a bit slow at the moment

<cbaines>the deploy I did last night hasn't quite worked, and a slow performing query is smothering the database

<reyman>Any help appreciated on rust that run gcc/clang compilation ...

<reyman>i'm not a specialist

<minima>hi, i use 'plain-file' to build a file out of a string; is there any smarter alternative to 'plain-file' when dealing with a scheme expression as opposed to a string? this is the particular context i'm referring to: https://bpa.st/6Z4A

<abrenon>hi guix

<ardumont>hello guix, does someone know if there is an equivalent command for `nix-locate "file"` or `apt-file search "file"` for guix?

<ardumont>as in what's the "package" holding this command "file" ?

<abrenon>hi ardumont ! it's a frequent question but unfortunately I don't think we have a satisfying solution so far

<abrenon>if you know the package is on your disk, you can directly query the store with find, but this won't help you if you're wondering which package provides this tool you want to try

<nckx>ardumont: There's a manual implementation, where you can ask here.

<ardumont>abrenon: thx (my solution is to use the command i mentioned to try and detect what could be the package name... ;)

<ardumont>nckx: i did not quite get what you meant

<nckx>You give us a file name, we answer which package contains it.

<ardumont>ah

<ardumont>ok

<nckx>SaaS.

<ardumont>lol, not right now, it's fine, I spent some time porting my home-manager config to guix home (not finished yet) and i usually felt short

<ardumont>when trying to find some package

<ardumont>and i was wondering if i could use a better way ;)

<nckx>It will come one day, but there's no (efficient) way for substitute servers to publish the list of files yet. Which is the only way this could work.

<abrenon>hi nckx

<abrenon>by the way, why isn't there an efficient way to do so ? What's the bottleneck ?

<nckx>Hullo.

<nckx>No, that's not what I meant. Let me rephrase: there's no (efficient) way to query the substitute servers for the list of files yet.

<nckx>Because there is no list.

<cbaines>I think there have been at least a couple of attempts at implementations

<cbaines>I think they've both focused on generating databases then downloading them for querying, rather than querying substitute servers directly though

<abrenon>oh, I see ^^

<cbaines>I think ludo did something a while back on this, but I don't have the link to hand

<nckx>Yes.

<nckx>ACTION considers ‘GET /guix/$revision/file-list.db’ a ‘query’. Sending actual per-file requests to the server would be silly.

<reyman>how did you do when a compiler search llvm-ar into CLANG, gnu/store/zfs41ixykm4z9162gajgs1ndc6bsbcqr-clang-13.0.1/bin/llvm-ar and not into gnu/store/llvm/bin/llvm-ar ?

<elevenkb>Hey there, I'm trying to package foliate (a GTK epub reader), but I get an error when I try to evaluate the definition in a repl, `unknown file:#f:#f: encountered raw symbol in macro output in subform socket of (current-location-vector)".

<PotentialUser-20>If i have an additional channel, specified like so: https://guix.gnu.org/devel/manual/en/guix.html#Specifying-Additional-Channels

<nckx>reyman: I'm also not familiar enough with clang to give a specific answer (and the answer will probably depend on the compiler in question, more than it does on clang). But the general answer is ‘patch the compiler, *somewhere*, to look in the right place’.

<nckx>elevenkb: Could you share the package?

<PotentialUser-20>Is it possible to guix pull/update only from my variant-packages ?? What would be the command for this??

<nckx>unmatched-paren: There's no gtkd patch that I'm missing, yet, right?

<elevenkb>nckx: http://paste.debian.net/1262243/

<nckx>PotentialUser-20: I don't think so. The closest would be to manually specify (commit "…") for the other channels. A ‘guix pull’ equivalent to --do-not-upgrade would be nice.

<PotentialUser-20>Some background for my question: Using guix pull i had to wait a while until the new substitues are available :-) I want only have the new changes in my own packages...

<PotentialUser-20>For checking this: Where is the "result" of the "guix pull" stored ??

<PotentialUser-20>(i mean the new scm files)

<elevenkb>nckx: it seems that I've fixed my problem. It seems to be a bad idea to start a repl using `./pre-inst-env guile` and `M-x geiser-connect`.

<nckx>elevenkb: I can't get it to evaluate to anything but #<package foliate@2.6.4 7822881946e0> in ‘guix repl’ (after ,use'ing some modules, but even before that I don't get your raw symbol error).

<nckx>Ah.

<reyman>yeah @nckx, another answer is to directly set "clang-toolchain" into input because it contains all in the same place /bin/

<nckx>:)

<elevenkb>Perhaps I should've known better b.c. that is implicit in the recommended setup in the manual. welp.

<nckx>reyman: …maaybe.

<nckx>I don't dispute that it works for the reason you give.

<reyman>i don't know how to patch, i have this => [529/1922] AR obj/third_party/icu/libicuuc.a => /gnu/store/zfs41ixykm4z9162gajgs1ndc6bsbcqr-clang-13.0.1/bin/llvm-ar failed

<reyman>i try to setenv(AR)

<reyman>to see if that change something ... ^^

<nckx>elevenkb: Does ~/.config/guix/current contain what you mean? The final answer is ‘in the store’, but guix/current always points to the right place.

<nckx>reyman: Good plan. Sorry, I can't say exactly what needs to be patch—or even if patching is the best option—without diving into the package myself. If using clang-toolchain as an input helps get you a rough working version, that's fine for now.

<nckx>ACTION away.

<elevenkb>nckx: I was just pointing out how the info manual section for Guix titled "The Perfect Setup" explains that you just have to add your checkout of guix to `'geiser-load-path'; presumably this means that you don't have to fiddle around with `pre-inst-env` to launch a repl.

<nckx>Sorry, that elevenkb: line was supposed to be for PotentialUser-20.

<nckx>ACTION awaay!

<PotentialUser-20>Aah. Thank you. My packages can have the same name / diectories ? So packages are used with the sequences in channels.scm (first my variants it there are any, then the guix ones) ?

<PotentialUser-20>* directories

<elevenkb>Ok, when I try something like `./pre-inst-env guix build hello` I get the following error:

<elevenkb>`build: error: failed to connect to `/usr/local/var/guix/daemon-socket/socket': No such file or directory`

<oriansj>lechner: yes, it is a local pi-hole

<oriansj>^in the future I hope to convert it to a guix setup but my wife would be upset if I caused an extended local network outage. So I am only converting the systems she doesn't use at this time to get the practice needed before I start attacking more critical infrastructure.

<ph03n1xaimverncc>@[unmatched-paren] Thanks a lot for helping me out yesterday. I was setting up a server. You're such a geniunely helpful person and I am highly grateful to you. I could learn a lot from you. This community is awesome and I appreciate being a part of this. Thank a lot again!

<ph03n1xaimverncc>Guix is amazing for servers and desktop. I'm on guix on a thinkpad (newer one, waiting to get my hands on an old OG thinkpad)

<pkill9>yea

<pkill9>guix is pretty neat in that you get the benefits of the immutable system partition style setup, but you can change it to how you want

<oriansj>ph03n1xaimverncc: I don't think the original thinkpad with a 386 can run Guix (insufficient RAM)

<ph03n1xaimverncc>Ohh

<ph03n1xaimverncc>pkill9: Highly agreed

<oriansj>but a post 2004 Thinkpad probably would be able to

<oriansj>such as the x60 and the x200 (both of which I know can run Guix)

<oriansj>which are the Original Libreboot Thinkpad targets if I remember correctly

<rekado>so, building a new system requires librsvg (and thus rust) because of the guix-icons derivation.

<rekado>I’d like to do without it for the aarch64 nodes

<ph03n1xaimverncc><oriansj> "such as the x60 and the x200 (..." <- I was thinking of the X-series

<ph03n1xaimverncc>Mine is X1

<elevenkb>I'm running Guix System, for now I'm dealing with the issue by setting `GUIX_DAEMON_SOCKET` before running `./pre-inst-env <cmd>` .

<ph03n1xaimverncc><oriansj> "which are the Original Libreboot..." <- I really want some nice Librebooted Thinkpad

<rekado> /gnu/store/s6l146bms1cxnqk2ja1rai4n7zhcmswd-rust-1.54.0.drv keeps failing because: Unable to run process '/tmp/guix-build-rust-1.54.0.drv-0/mrustc/bin/mrustc' - No such file or directory

<rekado>ACTION tries again with cores=1

<oriansj>rekado: don't forget you have 24GB of swap+ram if you want to build rust

<oriansj>^have^want to have^

<ph03n1xaimverncc>Wait, whaaaaa

<oriansj>ph03n1xaimverncc: I suggest the x200; it is really nice

<ph03n1xaimverncc>RMS uses it

<ph03n1xaimverncc>It has a good feel

<ph03n1xaimverncc>The monitor might not be good for movies and stuff but it's perfect for coding

<oriansj>The Ethernet port is also on the wrong side (it should be right next to the phone jack)

<oriansj>and not everyone needs or even wants 4K movies

<abrenon>and I missed the guix cafe again : (

<oriansj>well #guix-offtopic is usually good for some guix banter

<oriansj>does guix not have dict or dictd?

<efraim>rekado: is it using librsvg instead of (librsvg-for-system)?

<rekado>guix-icons references guile-rsvg

<rekado>and uses (gnu build svg)

<rekado>guile-rsvg uses (librsvg-for-system)

<efraim>oh it looks like (librsvg-for-system) on aarch64 now uses the rust version

<rekado>I’ll remove %base-packages-artwork and see if that removes the need for rust

<lechner>oriansj / Guix has been running on my wife's equipment for six months, and i am still married. it can work!

<rekado>works

<ardumont>lechner: lol, that's some good news!

<projectmoon[m]>is guix in any way practical for writing general guile programs? i.e. to use it as a dependency manager? or is guildhall better?

<projectmoon[m]>lechner: is she managing the updates? lol

<lechner>projectmoon[m] / no, i do everything but it's been super stable and there have been no odd looks, apart from the horns

<elevenkb>weird stuff, I'm building a `gjs` package and it totally should find the `main.js` but somehow it doesn't...

<elevenkb>i meant a`gjs` application.

<projectmoon[m]>looks like manifests and guix environment are what iw ant

<projectmoon[m]>although the examples in guile-curl are not ... working? 🤔

<jgart>sneek: later tell jackhill There's a building jpm package in guixrus https://git.sr.ht/~whereiseveryone/guixrus/tree/master/item/guixrus/packages/misc.scm#L1115 feel free to fix it up, update, and upstream it

<sneek>Got it.

<projectmoon[m]>the example just returns #f when curling a website...

<elevenkb>Hi everyone, please help me build this `gjs` application named `foliate`. Here's my package definition:

<elevenkb> http://paste.debian.net/1262256/

<projectmoon[m]>though it works at runtime paste. wierd

<projectmoon[m]>weird

<elevenkb>Currently when I `guix build foliate` and cd into the build directory and run `bin/com.github.johnfactotum.Foliate`, I get an exception: `bin/com.github.johnfactotum.Foliate`.

<elevenkb>sorry the exception is: `JS ERROR: ImportError: No JS module 'main' found in search path`.

<rekado>what’s the search path?

<elevenkb>rekado: How can I tell?

<jgart[m]>Should the erlang package have a search-path added to it to find libraries?

<elevenkb>ah, sorry mixing up conversations. I didn't intend to join the erlang related one.

<darosior>Hello, has anyone tried to cross-compile a Rust project from Guix?

<darosior>I'm setting up Guix for reproducible builds in our project and we want to target other systems / architectures (typically Mac and Windows). It looks like the builtin cross-compilation feature of cargo isn't available yet in Guix (https://git.savannah.gnu.org/cgit/guix.git/tree/guix/build-system/cargo.scm#n248), so i was wondering if anyone figured

<darosior>a workaround?

<jgart[m]>re erlang: https://lists.gnu.org/archive/html/help-guix/2022-10/msg00104.html

<elevenkb>Skimming the `gjs` source code available here: https://gitlab.gnome.org/GNOME/gjs/-/blob/1.70.0/modules/script/package.js#L159; I see no reason why my the program should not run upon invoking `bin/com.github.johnfactotum.Foliate`.

<elevenkb>Meh, I'll probably ask an expert over email.

<lechner>elevenkb / this is a runtime issue, isn't it?

<elevenkb>Yah looks like it.

<elevenkb>lechner.

<lechner>elevenkb / i have never used gjs but executables not finding things is pretty common in Guix

<lechner>elevenkb / the reference to Main.js either happens with the wrong leading path or none at all. the usual rememdies are to amend the path, or if that is not possible change the directory. there may also be solutions via environment variables

<elevenkb>thanks lechner. issue is that my understanding of how the search path works suggests that this just _cannot_ be happening :p

<elevenkb>checkout https://gitlab.gnome.org/GNOME/gjs/-/blob/1.70.0/modules/script/package.js#L159

<elevenkb>Like here's the unwrapped executable: `http://paste.debian.net/1262266/`.

<lechner>elevenkb / what is the installed path of Main.js, please?

<elevenkb>it is to be found in `guix build foliate`/share/com.github.johnfactotum.Foliate/com.github.johnfactotum.Foliate.src.gresource

<lechner>elevenkb / what is the value of 'foliate', please?

<elevenkb>it's a new package I'm trying to add to guix. The definition is here: http://paste.debian.net/1262256.

<lechner>elevenkb / the installed path of 'foliate' please?

<lechner>it will include a hash

<lechner>elevenkb / also, com.github.johnfactotum.Foliate.src.gresource does not look like Main.js

<projectmoon[m]>yes... i forgot to add -N to allow container to access network

<projectmoon[m]>using guix environment with a manifest.scm, does this sound like a sane idea to use for dep mgmt of guile scripts?

<elevenkb>lechner: just grep for main.js there. The gresource is some sort of bundle that packages all the modules together.

<lechner>elevenkb / my point is that the invocation in line 159 does not show the relevant path components. if grepping is needed, the issue could be in com.github.johnfactotum.Foliate.src.gresource

<lechner>in fact, gjs probably finds com.github.johnfactotum.Foliate.src.gresource since the error refers to its contents

<pkill9>any tips for using emacs to code guile?

<pkill9>i assume emacs is the best for it

<pkill9>oh nice there is guile studio https://elephly.net/guile-studio/

<whereiseveryone>has anyone gotten corfu completion to work with geiser-guile?

<lechner>cbaines / nckx / abrenon / regarding apt-file, i am not sure a database is needed. how many DISTINCT (as in psql) relative paths do our substitute servers provide? it would be the superset of all relative paths under the hashed folders in /gnu/store, but counting a path only once even if it appears in multiple versions (which is likely)

<ardumont>also, implementation-wise, maybe just having something that indexes information on the user's machine would be enough?

<ardumont>(afaict, that's what nix-index does for example, there is ~/.cache/nix-index/files sqlite db in there)

<mirai>can someone eli5 what "declarative counterpart of ___" means? (in the context of gexps)

<civodul>mirai: the "declarative counterpart of PROC" is an object (record) that represents the action that PROC would perform

<civodul>e.g., a <computed-file> record denotes what 'gexp->derivation' does

<civodul>often that's not a super useful piece of info :-)

<civodul>@ardumont indexing can be quite costly though, if you want to map files to actual package names/versions

<civodul>(hi! BTW :-))

<ardumont>hi!

<ardumont>yes, the first time we call nix-index, it's taking some time to finish ;)

<civodul>i prototyped something earlier this year: https://lists.gnu.org/archive/html/guix-devel/2022-01/msg00354.html

<civodul>ardumont: so how does nix-index work? it indexes files in the packages you have in the store?

<civodul>or just in your profile?

<ardumont>that's a good question, i never looked much into it

<ardumont>that'd be neater it looked in the user's profile

<ardumont>it has a flag to provide the <nixpkgs> though

<ardumont>-f, --nixpkgs <nixpkgs> Path to nixpkgs for which to build the index, as accepted by nix-env -f

<ardumont>(which is not set on my part, i'm no longer using channel for nix but flakes so no idea what happens there...)

<ardumont>oh your prototype, nice! your intro message is definitely my current predicament ;) i'll have a look, thx for the pointer

<civodul>heh :-)

<ardumont>albeit using apt-file or nix-locate

<ardumont>;)

<mirai>is there a way to inspect what the actual file resulting from (mixed-text-file) / (plain-file) / ... procedures will contain from a guix repl?

<ardumont>civodul: btw now i have a purism 14 with guix running with a current incomplete guix home (i'm not quite yet using it, i want the guix home to be done first ;)

<ardumont>(but so far so good)

<civodul>ardumont: nice!

<civodul>that's Guix System?

<ardumont>yes

<ardumont>i bought that one for it

<civodul>excellent :-)

<pkill9>nice

<ardumont>(from what i've read, people said it should have worked, i tried it out and it did ;)

<civodul>mirai: yes, see https://guix.gnu.org/manual/devel/en/html_node/Using-Guix-Interactively.html

<mirai>cool

<mirai>thanks

<ardumont>civodul: btw, with guix home, i've experimented to write scripts with "guix shell" shebang

<ardumont>one caveat i encountered is that long option we can't use

<civodul>ah yes, shebangs are limiited

<ardumont>(due to env limitation)

<civodul>*limited

<civodul>right

<ardumont>jsyk ;)

<civodul>jsyk?

<rekado>just so you know?

<ardumont>yes

<ardumont>(sorry)

<ardumont>but you already knew

<ardumont>maybe that'd be cool to have all long options mapped to short one?

<ardumont>(to work around that or that's a bad idea, no idea really)

<ardumont>the --container sounds appealing to me

<ardumont>(oh and guix is awesome, so thanks for it)

<ardumont>(mfw --container is -C as well, neat!)

<ardumont>(mfw: my face when)

<Michal_Atlas[m]>Or just use the guile \ way of doing things where the options are read from the second line if it's encountered in a shebang

<ardumont>ah it's --pure that's missing its short counterpart (sometimes, --container is just too "contained")

<ardumont>Michal_Atlas[m]: oh?

<ardumont>do you have an example by any chance, please?

<Michal_Atlas[m]>I meant this, if I understand your debate correctly: https://www.gnu.org/software/guile/manual/html_node/The-Meta-Switch.html

<stevenroose>So I would like to take a program that is in the guix main channel, but install a few different version of it. I can find the commit hashes of where the different versions were released, how would I go about this?

<stevenroose>Should I create custom package manifests for like program-1.0, program-2.0 and use the manifest syntax to fix the channel to the commit and then somehow install the programs from manifest?

<civodul>ardumont: i often use guix shell -CP or -CPN

<civodul>that's convenient when hacking on things that spawn processes and might leave them behind

<civodul>you know you can always exit 'guix shell' and everything's gone

<Michal_Atlas[m]>Doesn't that leave you in a shell without even coreutils though?

<abrenon>lechner: no idea ^^

<Michal_Atlas[m]><stevenroose> "So I would like to take a..." <- There's a package transformation for this, look through the manual. Something like --with-commit should allow you to straight up just install th package with that version, no editing manifests required.

<ardumont>Michal_Atlas[m]: yes, somewhat related to this, but my script are bash one for now ;)

<ardumont>thx

<ardumont>civodul: ack, for the --pure i need to figure out what's the shell doctor is saying i'm doing wrong with my .*profile stuff ;)

<ardumont>(because it's a mess ;)

<civodul>ardumont: fun fact: our cluster at work doesn't support user namespaces (-C), but --check reports tons of issues

<civodul>so colleagues end up running "guix shell --pure ... -- /bin/sh --norc" :-)

<civodul>good news: "make release SUPPORTED_SYSTEMS=x86_64-linux GUIX_SYSTEM_SUPPORTED_SYSTEMS=x86_64-linux" appears to work (well, i ran out of space shortly before completion...)

<civodul>i'll try to get the whole thing built overnight

<ardumont>lol @ fun fact

<ardumont>and interesting!

<civodul>yeah well, something we should fix on the cluster i guess

<civodul>but those startup files are kinda messy

<mirai>how can I get more info on this kind of error? "While executing meta-command: ERROR: 1. &gexp-input-error: #<unspecified>"

<civodul>mirai: it indicates that the unspecified value somehow made it into a gexp

<civodul>this can happen for instance if you do this: #~(this is my gexp #$(unless #t 42) <- bad)

<civodul>because (unless #t 42) returns unspecified

<civodul>(aka. "the unspecified value")

<stevenroose>Michal_Atlas[m]: but does that allow for installing multiple versions on the same machine?

<stevenroose>Ah I guess yes, I guess they would go in differente places in the store. Neat

<unmatched-paren>evening... afternoon... afterning?!... evenoon guix! :P

<lechner>ardumont / civodul / Hi, and thanks for the local index idea! when yearning for apt-file I'm mostly interested in executables that aren't available on my equipment. stripped of versions, the information may not change often and, when compressed, may be small compared to our other downloads so that it could potentially be searched locally, at least on demand and for the time being

<nckx>ardumont: That's what people do now: ‘ls /gnu/store/*-*-*/bin/foo’ or ‘find /gnu/store >db’. Nicer, but not much nicer.

<nckx>*Making a wrapper would be nicer, …

<lechner>i think it helps people understand Guix

<lechner>well, at least it helped me

<nckx>lechner: How would this database-less version work?

<lechner>like 'apt-file update'

<tricon>lechner: that uses a DB.

<lechner>tricon / we were talking about a public Postgres instance

<tricon>lechner: ah, my apologies.

<nckx>No we weren't.

<lechner>tricon / no worries, and thanks for the comment. a database format should be considered but i think with 200,000 or so records, a compressed JSON may do for now

<nckx>We were talking about downloading a (compressed) database of all file downloaded from the server, searched locally.

<nckx>‘Compressed JSON’ is still a database.

<unmatched-paren>nckx: wouldn't that file be modified constantly as packages are built on the CI?

<unmatched-paren>so you'd be downloading it again every time there's a new package built

<lechner>tricon / actually, i think i may have misread nckx's comments from earlier today. you deserve my apologies

<whereiseveryone>First guile core dev meetup will be in January to work on improving the debugger. Stay tuned!

<tricon>lechner: No worries at all! I enjoy these conversations that drive towards a potential improvement to the OS.

<nckx>unmatched-paren: Yes, that seems unavoidable with that model. You can optimise the download, but that's about it.

<nckx>The alternative is to ask servers for the file name directly.

<unmatched-paren>nckx: is either one "obviously" more efficient?

<nckx>You choose; you're defining ‘efficient’ :)

<unmatched-paren>i suppose you could have something like ``guix find --no-refresh'' to disable re-downloading the database for that invocation

<nckx>I'm sure whatever model is chosen will provide opportunity to add fine-tuning options.

<lechner>tricon / nckx / unmatched-paren / cbaines / having lived under apt-file for years, i believe this is a nearly perfect use case for GraphQL's microqueries. for Guix, the download database approach is particularly wasteful because we recompile so often

<unmatched-paren>ACTION doesn't know what graphql is for, looks it up to see

<nckx>lechner: Whom do you query?

<lechner>nckx / whichever substitute server i hope has an answer

<lechner>'guix install' could even take the most suitable package on its own even when given just the name of a file

<nckx>So it's useless without a connection to the Internet/a substitute server.

<lechner>without the internet, you cannot download substitutes

<nckx>Nor check you e-mail.

<unmatched-paren>Perhaps we could first try a GraphQL query to the CI, then if it fails fall back to a locally-built package file database?

<lechner>nckx / i think it's really hard to deduce from sources what will be installed

<nckx>lechner: You can't.

<unmatched-paren>The GraphQL query would simply ask the substitute server what it has in its own locally-built package file database...

<nckx>That's a fool's errand.

<lechner>nckx / yes, you can build

<nckx>That's not guessing.

<lechner>nckx / i think of deducing as more certain than guessing

<unmatched-paren>that's not even deducing :)

<nckx>Yes, it's knowing.

<unmatched-paren>it's just looking to see.

<lechner>unless some genius can analyze Makefiles and such

<unmatched-paren>not possible, really

<nckx>‘It's really hard to deduce what's in this encrypted file’ ‘You could decrypt it’ :)

<lechner>the source do contain all the information

<unmatched-paren>you could see what $PREFIX/... targets there are, but technically a makefile doesn't have to have a target to create a file

<unmatched-paren>e.g. ``scdoc foo.1.man > $DESTDIR$PREFIX/share/man/man1/foo.1''

<nckx>lechner: In theory, yes. Except the state machine you need to correctly extract it involves running through all the build steps.

<unmatched-paren>the parser could parse the shell script to see what files are being installed

<lechner>we could also create a cloud service to which participants upload file list of their local builds. i would be happy to host such a service if there are participants

<unmatched-paren>but then you have a massively overengineered mechanism for not much benefit

<nckx>That's never stopped anyone.

<unmatched-paren>heh

<unmatched-paren>i suppose we'd have to write a guile-graphql package to implement the query idea

<efraim>does anyone know if I can use image-type=efi-raw for an aarch64 efi image?

<unmatched-paren>doesn't seem to be one already

<nckx>Anyway, it's clear there are just 2 approaches here; whether one approach uses graphql or SQL like queries or regexes to type into the virtual /search.php text box in the sky is, to me, an almost irrelevant detail.

<mirai>What's causing this gexp in mixed-text-file to not see the (ice-9 format) module? https://paste.centos.org/view/122a4cbf

<unmatched-paren>mirai: you need to use-modules inside the gexp

<nckx>It would be cooler if there's some fancy modern algorithm that could bridge the two, but I don't know of any beyond ‘grep a huge local db that goes stale quickly, then go to the HTML search box in the sky’.

<unmatched-paren>nckx: why not do the web search first?

<unmatched-paren>then if there's no internet or the CI hasn't built the thing yet, try the local search

<nckx>I don't know why not.

<mirai>unmatched-paren: which of the gexps? Within a 'serialize-type' procedure?

<nckx>unmatched-paren: Why does order matter…

<unmatched-paren>mirai: any gexp that uses format

<nckx>Why not run them in parallel.

<nckx>Again, such a minute detail.

<mirai>won't that cause inefficiencies by importing the same module for each call to serialize-type ?

<lechner>ununmatched-paren / i am not sure it is overengineered. it is less centralized. you need an executable, and your peers tell you what they have to offer. it could even include the substitute servers

<unmatched-paren>lechner: no, no, i'm talking about the "parse the makefiles" idea :)

<lechner>unmatched-paren / i'd call it impossible

<unmatched-paren>though i don't really see the need for that service either.

<lechner>i could aid with reproducible builds, too

<unmatched-paren>the substitute servers would surely suffice, and people would be able to add packages that don't exist in base guix

<unmatched-paren>which would add irrelevant results, confusingly

<lechner>they are not irrelevant if they offer executables you need

<unmatched-paren>you wouldn't be able to tell where they came from

<nckx>lechner: Let's keep it tied to substitute servers. We eventually want to decentralise those (there is already very gross ‘P2P’ support over avahi) anyway, and the file-search function would move along with that. It shouldn't be a separate service.

<lechner>people can opt in. submitters would offer a list of hashes first. my service would return those it does not yet have

<lechner>and then receive whichever information participants are willing to share

<lechner>i have the P2P service working locally

<nckx>s/gross as in disgusting/gross as in rough/

<lechner>i got it

<nckx>Just for the record.

<lechner>it actually works well

<lechner>i love those 30 MB/sec rates!

<nckx>ACTION looks at their ath9k cowering in the corner. Hush, come back, it's OK, it was a joke; nobody does more than 10 MB/s.

<nckx>lechner: The next step would be to get rid of the ‘locally’. Which is what you'd be building with your extremely specialised distributed-file-list-service, so it makes sense to keep that & substitute distribution (and signature athorisation) together.

<whereiseveryone>sneek: later tell nckx how many cold hard belgian franks they pay for the substitute service?

<sneek>Okay.

<nckx>I've been told by someone I trust that too many microservices are bad.

<sneek>Welcome back nckx, you have 1 message!

<sneek>nckx, whereiseveryone says: how many cold hard belgian franks they pay for the substitute service?

<whereiseveryone>sneek: you guixer botsnack

<sneek>:)

<nckx>wat

<unmatched-paren>whereiseveryone: franks? O_o

<nckx>Do I show up as away?

<whereiseveryone>sneek: later tell nckx no you don't show up as away

<nckx>Apart from, y'know, actively talking.

<sneek>Got it.

<sneek>Welcome back nckx, you have 1 message!

<sneek>nckx, whereiseveryone says: no you don't show up as away

<whereiseveryone>jk

<nckx>I am being cybrebullied.

<whereiseveryone>I'll stop

<whereiseveryone>;()

<whereiseveryone>I just like to talk in the sneek fourth person sometimes

<lechner>nckx / why would i discriminate if someone has an executable that i want but which is not available from the substitute servers? i'd even allow participants to send a pending bug number, so people can throw in their support and upvote the patch

<nckx>I feel like I'm 11 again and Sophie's angry with me and sending her reps.

<nckx>ACTION still has a few Belgian franks in their pen-drawer, but they wouldn't even cover their own cost of physically converting them. I'm not sure if you had an actual question about hosting costs, whereiseveryone, so I can't answer seriously.

<whereiseveryone>I'm looking to host a substitute server again but trying to find a cheap way to do it

<nckx>lechner: I think you misunderstand what I mean, because I don't understand what you mean (oh dear).

<whereiseveryone>Are there cheap servers in Belgium?

<nckx>Starting questions with ‘why would I’ that the other party never claimed isn't a good start though.

<unmatched-paren>whereiseveryone: pretty sure the substitute server hosting is free; guix was gifted them, no?

<efraim>'FAT sector size mismatch (fs=1024, dev=512)' I wonder if my SD card is too big

<unmatched-paren>In some research centre or something...?

<unmatched-paren>In Berlin, not Belgium.

<lechner>efraim / has anyone seen a FAT section with 1024 bytes?

<lechner>nckx / people could also remind their peers to submit private patches, or packages in their private channels. the docs discourage private channels, and i could help

<nckx>whereiseveryone: Probably not; little is cheap in Belgium, certainly not power & land & bandwidth.

<whereiseveryone>unless I accept public donations to cover the costs of a substitute server for guixrus but not sure how I feel about that. Just don't want to pay $20 a month right now for a powerhorse

<nckx>lechner: You are clearly off inventing something no longer related merely to ‘which package provides ls’, and that's great, but it's also not related to what I was discussing.

<whereiseveryone>the US government should just provide Guix substitute servers covered by our tax dollars

<lechner>nckx / i don't get it. i would provide exactly that answer

<nckx>whereiseveryone: My server landing page used to literally say ‘I pay Belgian prices for this’, for that reason :)

<whereiseveryone>ah ok

<whereiseveryone>got it

<nckx>lechner: Then, to reverse the question: ‘Why would you’ not allow users to distribute substitutes over this network you envision?

<whereiseveryone>nckx: I saw someones dotfiles the other day who was using your substitute server

<whereiseveryone>can't remember now who

<unmatched-paren>whereiseveryone: i use that server :P

<nckx>That's OK, it proxies through a caching VPS in Germany now.

<whereiseveryone>unmatched-paren: maybe it was you then

<lechner>nckx / users may only wish to share the package definition

<nckx>That's why the querying percentage-going-up is relatively slow, because that can't be reliably cached, so that's you grinding my spinning HDDs at home. The actually transfer is cached.

<whereiseveryone>nckx: Can you serve substitutes for guixrus? I'll send some belgian franks your way as a donation

<unmatched-paren>whereiseveryone: aaaaa belgium doesn't use franks anymore :P

<whereiseveryone>belgian franks = euro

<nckx>It's OK. I literally ate a waffle today. Multiple. Tomorrow, I might visit manneken Pis again.

<unmatched-paren>lechner: i think this has actually been suggested and implemented in a patch before (wasn't that what ``guix potluck'' was for?)

<nckx>Minus the decentralisation (IIRC), yes!

<mnhrdt>are there slides/recordings for today's Café Guix ?

<whereiseveryone>mnhrdt: you'll probably need to ask simon or ludo

<nckx>whereiseveryone: Done.

<unmatched-paren>whereiseveryone: looks like there's already a pretty good intro to gexps in the manual https://guix.gnu.org/manual/devel/en/html_node/G_002dExpressions.html#G_002dExpressions

<oat>Hello I have installed Guix I want to contribute. Do you have a config.scm to install the development environment?

<unmatched-paren>oat: you don't use config.scm to install the development environment :)

<unmatched-paren>you can do this: ``guix shell -D guix''

<unmatched-paren>which creates a shell containing all the packages that guix depends on

<unmatched-paren>make sure to read https://guix.gnu.org/manual/devel/en/html_node/Contributing.html

<whereiseveryone>oat: here's tldr of the steps you need to run: https://git.sr.ht/~whereiseveryone/dot/tree/master/item/bin/executable_guix-prepare-tree

<whereiseveryone>to get started hacking on guix

<lechner>isn't there a chapter called "the perfect setup"?

<unmatched-paren>lechner: yes, in ``contributing''

<whereiseveryone>that's for geiser iirc

<whereiseveryone>which geiser is not the perfect setup if you're on a foreign distro it seems

<lechner>okay, that's not needed

<whereiseveryone>i think char[m] and singpolyma don't use geiser iirc

<whereiseveryone>but ideally you'd use geiser

<whereiseveryone>if it worked without a hitch with guix

<lechner>things like ",q" may belong into the advanced class

<sam-d>I want to create a package definition where the code is in one repo and the config in another. What is the guix way for such a case? Can we have several origin clauses?

<pkill9>yes, you can provide an origin as an input

<nckx>whereiseveryone: <geiser> I bet <50% committers don't use it or the ‘perfect’ setup, and that's OK.

<unmatched-paren>pkill9: i don't think that's actually necessary

<unmatched-paren>just ungexp-native an origin

<unmatched-paren>#+(origin ...)

<pkill9>ohh nice

<pkill9>that's cool

<whereiseveryone>nckx: ya but I really want to use it. I really do

<whereiseveryone>I want the slime

<unmatched-paren>pkill9: technically you can do #$package, but that's bad because transformations won't work

<unmatched-paren>uh, could someone please merge 59670? i just realised it causes aerc to fail to build :(

<unmatched-paren>s/it/zoxide/

<unmatched-paren>because aerc depends on zoxide...

<unmatched-paren>and zoxide fails to build currently

<sam-d>so in the inputs I ungexp my second origin?

<sam-d>and then the final derivation will have access to both during the build phase? And will they be in the same directory?

<whereiseveryone>Does Guix really need to package the world or specialize on high quality packages for some subset of the world?

<efraim>looks like our esp partitions are made with a sector size of 1024 by default, which causes errors with u-boot

<whereiseveryone>For example, I think we have the best Common Lisp package collection out there. Even better than Nix.

<tricon>whereiseveryone: I'd rather not run a hodge-podge of GNU/Linux distros and their variants if I can do-it-all with Guix while having the benefit of such.

<lechner>one day, we may fit debian into /gnu/store!

<tricon>lechner: hah!

<jgart[m]>I just think that we don't need to package the world maybe.

<jgart[m]>Might make maintenance more maintainable by the number of contributors we currently have

<lechner>we don't. we untar the world. the guix package manager could be the mother of all

<jgart[m]>We don't have the number of contributors or funding that nixpkgs has, for example

<jgart[m]>Plus, I like the idea of Guix just providing really powerful tools for us to automate using the exact versions we need in a dev project

<jgart[m]>So maybe we should concentrate on that instead of hash bumping?

<nckx>unmatched-paren: Oof. Testing.

<unmatched-paren>nckx: Don't you just love updating Rust packages.

<jgart[m]>I remember a common lisper/nix user telling me that they didn't see the point in packaging a particular version of a series of packages but instead just generating the package versions you need for your particular project and then "locking them" in

<nckx>ACTION scowls at unmatched-paren. >:(

<jgart[m]>I think we should work on improving our importers to life hack level

<jgart[m]>singpolyma: thinks that we should improve our importers

<unmatched-paren>there is one thing i think we could improve with guix import crate

<unmatched-paren>currently, it doesn't read conditional dependencies

<jgart[m]>I won't touch any more rust until I fix or create a new etc/committer.scm that does what I envision it doing

<nckx>jgart[m]: There are channels that package an automated part of the world, with the expected trade-offs (some stuff is just uselessly broken, but there *is* more stuff). I think that's the right model: a well-curated core; channels for bots. Maybe our core is too big if it's unmaintainable, but I still think the model's OK.

<jgart[m]>and the importer needs to not print unknown-license! blah blah

<nckx>Please do improve the tooling!

<jgart[m]>I'll have to hack the importer for my use case

<jgart[m]>I think our core should be way smaller

<jgart[m]>and way more powerful

<jgart[m]>that would be the ideal

<jgart[m]>for me atleast

<unmatched-paren>guix's core is actually very, very small

<unmatched-paren>derivations, etc

<jgart[m]>I just want the binary seeds and everything in guix/ lol

<unmatched-paren>it's just scheme lets us layer many abstractions on top (file-likes, packages, etc)

<nckx>unmatched-paren: That's a valid definition of core. I meant (gnu packages). ‘Core distro’, I should've said.

<jgart[m]>well not even everything in guix/

<jgart[m]>but maybe

<jgart[m]>give us the tools to build our islands

<nckx>unmatched-paren: I'm on a stock ThinkPad, so this'll take a while to build test, but I am on it.

<unmatched-paren>nckx: thank you!

<jgart[m]>and channels would be even more first class

<unmatched-paren>but what if i'm lazy and can't be bothered to build an island :(

<jgart[m]>unmatched-paren: see guile 0.1

<nckx>ACTION isn't used to a puny 4-core CPU anymore; this won't heat the room at all; goes to get firewood. o/

<jgart[m]>unmatched-paren: I meant v0.0: https://git.savannah.gnu.org/cgit/guix.git/tree/guix?h=v0.0

<jgart[m]>unmatched-paren: then just fill up a little kayak with what you need

<jgart[m]>I'd like guix v0.0 but with a more powerful core and powerful importers and robust guix libraries and utils to then build the islands

<jgart[m]>or kayaks

<unmatched-paren>jgart[m]: guix v0.0 is literally just a thing for asking the nix daemon to do stuff with guile though...

<jgart[m]>anyways, I'm day dreaming. Back to continuing on the Debianic epic

<jgart[m]>unmatched-paren: Ideally guix v0.0 wouldn't talk to nix

<jgart[m]>to the nix-daemon I mean

<jgart[m]>there would be no C++ only Guile daemon

<jgart[m]>or Chez or CL daemon

<jgart[m]>pick your poison

<oat>whereiseveryone: lechner: The chapter is not educational.

<jgart[m]>which chapter are you talking about?

<jackhill>hi Guix!

<sneek>jackhill, you have 1 message!

<sneek>jackhill, jgart says: There's a building jpm package in guixrus https://git.sr.ht/~whereiseveryone/guixrus/tree/master/item/guixrus/packages/misc.scm#L1115 feel free to fix it up, update, and upstream it

<jackhill>jgart[m]: cool, thanks, I'll have a look

<jgart[m]>jackhill: it doesn't install the jpm binary so you'll have to do that. I have some commented out code but it's probably no good

<jgart[m]>but might serve as a template ;()

<jackhill>it's helpful to have a starting point. I'm also glad the jpm has a bootstrap script rather than requiring jpm…

<bavier>hi Guix! I haven't been here in IRC for quite a while...

<nckx>Hi!

<unmatched-paren>bavier: hello!

<jackhill>jgart[m]: did you ever run into "error: Permission denied: /gnu/store/waq4yyrvif5j05yia80j4n8cd6bgq1ra-janet-1.25.1/lib/janet/.manifests" If so, what was the solution?

<jgart[m]>for the jpm package?

<jgart[m]>or janet?

<jgart[m]>I don't remember that one

<jackhill>for jpm

<jgart[m]>bavier: you've been in the matrix?

<jgart[m]>I'm sending this from the matrix right now

<jgart[m]>hmmm ya don't remember that error

<bavier>jgart[m]: I'm in the matrix channel but I really don't check in on it.

<jackhill>jgart[m]: ok no worries. Probably worthwile to read the source anyway to make sure it's doing the right thing.

<jgart[m]>Have you been to the Guix discord channel? They have twice as many users as Libera

<unmatched-paren>jgart[m]: that can't be right

<jgart[m]>jk, that would be a sign of the end of days jk

<bavier>heh

<unmatched-paren>any discord channel is unofficial, obviously, and i doubt many people interested in a 100% free os would use discord :(

<unmatched-paren>s/:(/:)/

<unmatched-paren>haha

<lechner>musk is right about those bots

<jackhill>jgart[m]: guixrs is setting destdir, and I'm not yet…

<nckx>ACTION was this close to tapping the sign <https://www.reddit.com/r/freesoftware/comments/u68ff3/any_free_discord_clientsfrontends/> but OK.

<the_tubular15>To be fair, there's other reasons to be interested in guix that purely free software.

<nckx>lechner: I wish he would stop hoarding all his bots and share them with us.

<nckx>Sure, but they wouldn't be relevant here.

<jackhill>jgart[m]: but either way, I'd still feel better knowing how it works and why I should set things

<jgart[m]>unmatched-paren: there's no guix discord

<jgart[m]>there will never be...

<jackhill>jgart[m]: yep, setting DESTDIR allows the build to compelete. Now to see if what it produced is reasonable…

<unmatched-paren>nckx: The bots have resigned en masse due to an email demanding that they work long, hard hours.

<jgart[m]>I am not an expert on janet tbh

<nckx>Daily reminder that setting DESTDIR is almost (but not) always a mistake.

<jgart[m]>I think bakpakin would say to read the jpm source

<jgart[m]>We'd need to see what jpm install does

<nckx>unmatched-paren: And lack of snacks.

<jgart[m]>and jpm test

<jgart[m]>but maybe I am thinking too far ahead

<jackhill>nckx: yeah, I alrady have a patch to not use DESTDIR for janet.

<jackhill>whoops, it didn't actually install anything

<jgart[m]>chicken support in Guix is quite nice

<nckx>Okido / 😃

<nckx>jgart[m]: Do you see the 0x11s you're (probably: Matrix is) sending?

<jgart[m]>I wish erlang was like chicken in Guix

<unmatched-paren>nckx, jgart[m]: i don't see any 0x11s

<unmatched-paren>and i'm not on matrix...

<jgart[m]>jackhill: I think that a janet importer should probably parse this? https://github.com/janet-lang/pkgs

<jgart[m]>There's no fancy json API as far as I know

<jgart[m]>I don't see any 0x11

<nckx>I feared as much. logs.guix also strips it https://www.tobias.gr/0x11.png

<jgart[m]>have you taken the red pill or the blue pill?

<nckx>I took both

<nckx>was I not supposed to.

<jgart[m]>that'll determine whether you see 0x11 or something else

<nckx>ACTION was hungry :(

<nckx>Anyway. Clearly some formatting thing.

<unmatched-paren>nckx: https://xkcd.com/566/ :)

<unmatched-paren>(the second row...)

<jgart[m]>nckx: Oh that was probably me imagining that irc supports markdown code brackets

<jackhill>jgart[m]: probably. Or maybe shell out to jpm? Perhaps the former. Importer is out of scope, I think, for the current patchset. I plan to submit it once I get a build system a a few example packages, leaving importing as separate work later.

<nckx>unmatched-paren: :)

<jackhill>yeah, this definitely isn't right: https://paste.debian.net/1262303/

<jgart[m]>Should Guix have an xmpp room also?

<jgart[m]>or meh

<unmatched-paren>irc is sufficient

<jgart[m]>jackhill: sounds good to me

<jackhill>just use biboumi to join this room is what I'm inclined to do for xmpp

<jgart[m]>janet support in Guix would be so awesome

<jgart[m]>bootstrapping jpm is such a pain

<jgart[m]>the void linux jpm package is broken last time I tried

<jgart[m]>jackhill: re xmpp: sounds right

<jgart[m]>matrix guix people didn't get the memo on the matrix irc bridge to #guix:tchncs.de

<jgart[m]>That said, it's nice to have decentralized communities and guix rooms

<jgart[m]>like zig community does

<jgart[m]>or mint lang community does in contrast to elm

<jgart[m]>anyways, I'm rabbit hole diverging now

<jackhill>jgart[m]: I probably should have stuck closer to you definition to start with, but banging my head against it is a good way to understand. What I have so far: https://paste.debian.net/1262304/ I'm not sure yet about needing to wipe out the default configs.

<jackhill>heh, glad to hear that it's not just us.

<jackhill>I like the idea of using copy-build-system. Left to my own devices I probably would have started with gnu-, but copy- seems more appropriate

<jackhill>jgart[m]: are you sure the guixrus jpm package works? I don't think it is for me.

<jackhill>jgart[m]: one problem/fix: setenv doens't need the = like make flags

<podiki[m]>I believe this came up before but not seeing a bug report..."sudo herd rules udev" does not work yet referenced in the manual

<podiki[m]>I can submit a bug report, but anyone have any leads? or workaround in the meantime?

<podiki[m]>there's /run/current-system/etc/udev/rules.d to answer that

<apteryx>ls /etc/udev/rules.d

<apteryx>why do we need a 'rules' action?

<apteryx>we should just delete that bit from the manual

<podiki[m]>well it is in the manual so I presume it existed at one point?

<apteryx>/etc/udev is about as standard as it gets, so it doesn't need to be treated specially

<podiki[m]>I'm not sure what it did, perhaps printed out the rules.d directory?

<apteryx>at least that's how it's documented

<podiki[m]>oh right, didn't finish reading :)

<podiki[m]>we could replace that line in the manual just saying the system udev rules directory directly

<jackhill>jgart[m]: ah, this looks better! Now to see about tests and if it actually works https://paste.debian.net/1262311/

<lechner>Hi, are there any secrets in the store?

<singpolyma>lechner: no

<singpolyma>Store is world readable

<lechner>singpolyma / is there a plan to ever allow them?

<podiki[m]>well there shouldn't be any secrets

<podiki[m]>as they are not secret

<podiki[m]>it has come up before but as far as I know there's not good proposal on how to do that exactly, though some definite uses that people want (say encryption keys for boot so only one password)

<lechner>to rephrase, is there anything in the store that anyone would be uncomfortable sharing?

<podiki[m]>there shouldn't be (I'm allowing that something might have sneaked in that shouldn't have, but I don't know of any)

<podiki[m]>afterall, we have publicly available substitutes that anyone can download

<mirai>is there a way to "warn" and deprecate a field when using define-configuration?

<singpolyma>I would love a solution to this, but admittedly have not spent much time trying to think of a solution myself yet

<apteryx>mirai: not directly from the declaration

<apteryx>what I'd do is rename the field and wrap it with a manually defined accessor of the old name that warns

<apteryx>podiki[m]: I've pushed 3e14e316a5, which removes mentions of 'herd rules udev'

<apteryx>thanks for the report!

<mirai>apteryx: do you have an example of it?

<apteryx>search for bootloader-configuration-target

<apteryx>it uses guix records but the idea is the same

<jackhill>jgart[m]: also, do you know why you have pkg-config in native-inputs? I'm not sure if it's needed.

<podiki[m]>apteryx: thanks!

<jackhill>anyways, still a fair amount of work to do to make sure the default config shipped is correct for guix, etc.

<mirai>apteryx: should I replicate the define-with-syntax-properties snippet per field I want to deprecate?

<mirai>apteryx: I'm converting from a define-record-type* to define-configuration, so far it looks like this (https://paste.centos.org/view/714b8e0e)

<mirai>and I'd like to take the chance to deprecate the redundant -dir shorthands rather than have both 'music-dir' and 'music-directory'

<podiki[m]>does the linux-module-builder now have the (very slow) build-doc phase from linux-libre?

<podiki[m]>system reconfig is very slow because of that (is it needed there?)

<apteryx>so in the new define-configuration record I'd use d 'music-directory', and below I'd define a music-dir deprecated accessor

<apteryx>podiki[m]: looks like

<apteryx>and no it shouldn't be needed; I didn't know that inherited all the phases from linux-libre

<podiki[m]>apteryx: I haven't looked at the code either, but that was my guess

<podiki[m]>why is that phase slow anyway, it can only run single-threaded for some reason? (not a big deal for a kernel compile though it is a decent chunk of time)

<mirai>apteryx: but there's also 'playlist-dir' and possibly the 'address' field as well, should I copy-paste the "(define-with-syntax-properties (warn-target-field-deprecation" from bootloader thrice and tweak the message?

<apteryx>podiki[m]: sphinx is slow

<apteryx>and SPHINXOPTS=-jX doesn't typically work

<apteryx>(because of limitations of Sphinx)

<apteryx>I tried it there, didn't cause more than one CPU to be used

<apteryx>podiki[m]: does this look fine to you? https://paste.debian.net/1262322/

<podiki[m]>apteryx: yes, think so. that phase exists even when it doesn't run (for the < 5.15? kernels) right?

<podiki[m]>might be quicker for me to wait for this change, pull, and reconfigure; wow sphinx is slow :)

<podiki[m]>ah no, I think that phase doesn't get added if build-doc? is not true

<apteryx>podiki[m]: hm, good point, the phase may not exist

<podiki[m]>will it get the #:build-doc? argument? could set that directly

<podiki[m]>or I guess check if that phase is in the inherited list and then delete?

<apteryx>alist-delete (which delete in modify-phases calls) doesn't error when attempting to delete a missingkey

<apteryx>so we should be good

<apteryx>e.g.: (alist-delete 'bob '((toto . 5) (titi . 6))) -> ((toto . 5) (titi . 6))

<podiki[m]>ah, nice

<apteryx>pushed!

<podiki[m]>thanks! 2 for 2 in quick changes :)

<mirai>is this right? https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/services/configuration.scm#n439

<podiki[m]>meanwhile I will learn about udev rules (not related to guix), have one that is not working as far as I can tell....

<mirai>it doesn't look quite right to assume any list is an alist

<podiki[m]>looks more like saying any alist is a list, but that doesn't mean it is an alist, true

<apteryx>podiki[m]: do you have experience with RPi and Guix?

<apteryx>I'm wondering if the the nonfree firmware situation has evolved since I had last checked

<podiki[m]>separately yes, together no (not yet? I use one as a home server with Arch currently, would require me using more docker on Guix I think)

<podiki[m]>I'm curious myself, but not in the know

<apteryx>OK!

<podiki[m]>on that topic, anyone know similar devices which are more open for firmware? would be nice to play with guix on one

<apteryx>the_tubular15:

<apteryx>err, sorry

<podiki[m]>apteryx: last you checked was it that there is some non-free bootloader/firmware so you have to sort of bootstrap from another system first?

<bavier> podiki[m]: the Olimex boards, I thought, had pretty good open firmware support.

<gnucode>bavier: my understanding is that those Olimex boards are very close to or are RYF

<podiki[m]>RYF?

<mirai>podiki[m]: Respect Your Freedom

<unmatched-paren>podiki[m]: https://ryf.fsf.org

<unmatched-paren>it's not a very useful standard, because it allows nonfree firmware in secondary processors

<unmatched-paren>presumably because there is no free firmware for any of them

<podiki[m]>ah

<podiki[m]>good to know, thanks all

<apteryx>podiki[m]: it was a summary check; the GPU required nonfree blobs just to boot

<apteryx>and since RPi booted of its GPU ^^'

<podiki[m]>I was recently very annoyed when my Pi suddenly wasn't on the network due to a firmware change from upstream which changed network device names

<podiki[m]>I need more freedom!

<gnucode>podiki[m]: I feel like we have few affordable RYF options...

<lechner>Hi, can the store contain empty directories?

<unmatched-paren>lechner: i think so?

<lechner>how about "special" files?

<unmatched-paren>wdym by that?

<lechner>device nodes

<unmatched-paren>-.o.-

<nckx>…no.

<lechner>pipes?

<nckx>Try it!

<nckx>(No.)

<nckx>lechner: Are you planning something particularly nefarious or just curious?

<florhizome[m]><podiki[m]> "on that topic, anyone know..." <- What about the pine64 ones?

<lechner>nckx / nefarious!

<podiki[m]>florhizome: I have not looked into those, do they have a SBC-type? I know of their phone, watch, etc stuff

<rekado>I have a rockpi, but haven’t tried to install Guix System on it yet

<nckx>lechner: I look forward to it! Anyway, here's the list of boring allowed types: https://git.savannah.gnu.org/cgit/guix.git/tree/nix/libstore/local-store.cc#n381

<nckx>Of course that doesn't mean there can't be a bug somewhere else. Good luck.

<podiki[m]>apteryx: I see some CI failures, might be from our build-doc fix, see e.g. https://ci.guix.gnu.org/build/170884/details

<podiki[m]>it failed at install-doc...

<podiki[m]>same with a few other driver related stuff I just checked

<podiki[m]>apteryx: so I think that needs to be deleted too from the module builder, it is added in the same if build-doc? part of the linux-libre build

<oriansj>is it just me or is there no difference between writing one's own shepherd service and creating one for guix mainline?

<gnucode>looks like emacs 29 is coming out soon. and when you compile emacs you can optionally AOT compile all the native elisp. that's kind of cool.

<gnucode>oriansj: well if you contribute your service upsteam...other can use it.

<oriansj>well right now I am looking at having to write custom shepherd services for iwd and a generic service for running scripts

<oriansj>which seems like something that should have been done a long time ago

<gnucode>iwd is intel's newest wifi daemon right?

<oriansj>it has been in Guix for a few years

<oriansj>and it works great

<oriansj>even on Debian's old and crusty

<oriansj>but right now you have to manually start it and all other distros seem to have an easy to enable/disable service

IRC channel logs

2022-11-29.log