IRC channel logs

<ph03n1xaim[m]1>Heyya, can anyone help me with setting up vcs_info on zsh? Like it literally shows ${vcs_info_msg_0_} without the git info being shown

<ph03n1xaim[m]1>The var isn't getting substituted for some reason

<kori>is there a way to pretty print things like %base-services?

<ph03n1xaim[m]1>Pretty print where?

<unwox>kori: guix repl -> ,use (gnu services base) -> ,pp %base-services

<unwox>i would call that pretty though

<kori>ph03n1xaim[m]1, the guix repl

<kori>unwox, thanks!

<kori>a better question would be: is there a way to get the code that defined %base-services interactively? (i.e. without grepping the source code)

<kori>(I guess this would be a question better suited for #guile...)

<kori>ugh... I'm still running into public key authorization issues with guix deploy... this is tough. I added the key to the guix-service in the target machine, but I ran cat /etc/guix/acl and it's not there...

<kori>(before trying to guix deploy, that is)

<unmatched-paren>morning guix!

<zamfofex>????

<kori>uh. I did it?

<kori>lol

<ph03n1xaim[m]1><unmatched-paren> "morning guix!" <- Morning

<zamfofex>Hello, Guix! I???ve been making experiments towards bringing npm packages to Guix again. Last time I tried it (a few months ago), I was let down because it *really* did seem like most of npm was necessary to build even a single popular package like JSDOM or jQuery. And if you follow the transitive dependencies+devDependencies tree, you do end up concluding that.

<zamfofex>But I figured that most packages provide convenience utilities in devDependencies that are not strictly necessary to build them. If you take a moment to think about it, what most packages do is (optionally) compile TypeScript, and then (optionally) perfom some transpilation or bundling.

<zamfofex>Now, TypeScript is fairly complicated, so I???ve been investigating replacing it in an ad???hoc way (i.e. in a case???by???case basis) with ???rust-swc??? (since it is already packaged), but it seems to have been failing to build for a long time now.

<zamfofex>I???ve been trying to create a simple JSDOM package with my npm import script, and it does seem like most packages just work naturally (build successfully), and a few that don???t only require me to skip the ???npm install??? (???configure???) phase, and sometimes also disable tests.

<zamfofex>The biggest issue I???m running into is that there are a few packages that require bundling and TypeScript compilation, but my hope is that once ???rust-swc??? is fixed (and once Node is updated), I should be able to get a working JSDOM package! (And potentially other packages too.)

<ph03n1xaim[m]1>I think npm in guix repo is outdated as well

<ennoausberlin>apteryx: Had you checked if your mcron job stays as zombie?

<yarl>Hi guix!

<zamfofex>ph03n1xaim[m]1: npm is provided by the Node package, so yes.

<unwox>zamfofex: there is also esbuild for compiling ts iirc

<rekado>we tried to use swc first (to build .ts and minify JS), but then esbuild became available and we???ve been using it to minify modern JS ever since.

<zamfofex>I see! I???ve been looking into it. What is it currently used for in Guix?

<rekado>minification of JS, e.g. in R packages

<ennoausberlin>Hi guix. Is there a rule which packages are built in what order on the substitute servers?

<rekado>see gnu/packages/cran.scm for examples

<rekado>ennoausberlin: all are built, and the order is determined by the dependency graph

<ennoausberlin>rekado: That means, if no substitute is available the build probably failed?

<ennoausberlin>because bordeaux sometimes gives me a substitute by the main server does not

<ennoausberlin>*but

<rekado>no, it doesn???t necessarily mean that the build failed

<rekado>you can check ci.guix.gnu.org for build details

<ennoausberlin>rekado: I use guix weather usually. My idea is, that packages which are requested for go up in priority on the server. Is there some kind of mechanism or am I completly wrong?

<ennoausberlin>rekado: I dont know how powerful your build servers are, but I guess it build jobs are queued in some way or the other

<brendyn>i have a pam-limits-service setting 'nofile to a larger number, but ulimits -Hn still shows it as 4096. any ideas why it isnt working?

<civodul>Hello Guix!

<unmatched-paren>morning civodul!

<yarl>Hello civodul!

<xd1le>o/

<faust45>hi guix

<faust45>need your help

<faust45>how i can create named profiles?

<civodul>faust45: hi! you can do things like "guix package -p ~/my-custom-profile -i PKG"

<civodul>see https://guix.gnu.org/cookbook/en/html_node/Guix-Profiles-in-Practice.html

<faust45>thanks!

<rekado>in a little more than 6 hours we will temporarily lose access to the SAN.

<nckx>Morning, Guix.

<nckx>ennoausberlin: Request data is not used in any way.

<ennoausberlin>nckx: OK. Thank you for confirmation

<xd1le>o/ morning

<xd1le>nckx, there's a spam/bot message

<xd1le>I'm not sure if you want to ban that or whatever

<zamfofex>I think that has already been taken care of.

<xd1le>ok

<nckx>Your client must not display bans. But thanks.

<civodul>hey goggles-bot

<civodul>let's see if goggles-bot understands what a ???? is

<civodul>still doesn't: https://logs.guix.gnu.org/guix/2022-11-18.log

<civodul>damnit

<rekado>civodul: something???s not rendering right on logs.*

<civodul>or maybe that's rendering this time

<rekado>even things like ???

<rekado>the log file looks fine to me

<rekado>oh, wait

<civodul>no it has question marks

<rekado>it does not look right

<nckx>bayfront ~$ less <log file>: [11:36:42] <civodul> let's see if goggles-bot understands what a ???? is

<nckx>Yah.

<civodul>i thought 81920f51177ede32544306724e5bbfde8040f6f5 (maintenance) would fix that

<rekado>2022-11-03.log has proper quotes

<nckx>When was goggles-bot switched over to?

<civodul>yes

<civodul>oh i see, the env vars are inherited but glibc-utf8-locales is not in the container

<civodul>grr

<civodul>so now: curl http://bayfront.guix.gnu.org -H "Host: guix.gnu.org" -> 308

<civodul>curl https://bayfront.guix.gnu.org -H "Host: guix.gnu.org" -> ???

<civodul>wget -6 -O- https://bayfront.guix.gnu.org --header="Host: guix.gnu.org" ???

<nckx>Confirmed for both 4 & 6. Thanks!

<nckx>You just had to sneek wget in there, didn't you.

<civodul>of course

<civodul>i'm a native wget speaker

<nckx>:)

<nckx>This has nicely kept you busy until noon.

<nckx>I see ???notify: [gnu-master]??? on bayfront so, if honoured, the switch should be over in an hour.

<civodul>i haven't pushed the dns change yet

<civodul>"how to keep oneself busy, lesson 1"

<civodul>"dig @bayfront.guix.gnu.org guix.gnu.org" -> bayfront

<civodul>i only see the A record tho

<civodul>goggles-bot: what's this? 🐘

<civodul>yep, an elephant! https://logs.guix.gnu.org/guix/2022-11-18.log

<civodul>i did something useful today 🙋

<jonsger>Guix on its why of becoming the 1st joice distro for young lads, who grew up with emojis everywhere :P

<jonsger>s/why/way/g

<civodul>emojis are a crucial part of our language 👍

<jonsger>ACTION doesn't even know how to typ them on his keyboard :(

<rekado>civodul: yay!

<rekado>thumbsup emoji, dance emoji!

<civodul>requests are arriving on bayfront

<civodul>seems to work!

<civodul>that makes repology happy apparently

<rekado>hah

<rekado>no more DFN blocking

<civodul>yeah

<rekado>pretty annoying, that.

<rekado>ACTION updates firmware for build farm hardware

<ngraves>thanks nckx, your solution seems to repair my store. It there a way to understand what happened ? It repairs a lot of binaries (still running)

<nckx>I have no idea what happened, I'm afraid. Are there any I/O errors in /var/log/messages around the time this happened? Or anything unusual related to storage?

<nckx>USB can be flakey, but it would be very unusual (to the point of implausible) for it to affect other storage. Is it possible that your repartitioning/formatting accidentally touched the wrong drive, even briefly?

<rekado>on aarch64 /gnu/store/77ngkp1rns418pqp4887gdysd785zlm3-coreutils-minimal-8.32.drv failed its tests, but it succeeded when built with ‘--cores=1’

<nckx><i only see the A record> That's expected, A is dig's (only) default. I wonder if that will ever change.

<nckx>AAAA is good too.

<nckx>civodul: Thanks for fixing Unicode. Emoji fun aside, ‘…’ is a bit more important and was also broken.

<nckx>.org does not allow emoji in domain names. Yet.

<nckx>ACTION meant the quotes, but ‘…’ was also broken so the entire string became ?????. Anyway.

<rekado>same with /gnu/store/69c44067gmcnsqrhz0a8ipipwl33918a-libunistring-0.9.10.drv on aarch64; cores=1 makes it work

<ngraves>I still have some issues. guix gc --verify=contents,repair runs fine until the end, but doesn't seem to change files in the store. If I run it again right after, I get the same output, the same repairs

<fidel_>I discovered the dirvish Emacs package (https://github.com/alexluigit/dirvish) today and was dismayed that it's not in guix. Anybody knows of any efforts to package it? If not I will work on it this weekend.

<ngraves>There's a version of dirvish already written in git.sr.ht/~abcdw/rde in rde/packages/emacs-xyz.scm

<fidel_>ngraves: great! any reason not to bring it to guix?

<ngraves>I have no clue, but probably no.

<ngraves>There's a small arguments part, but it seems well written. If you test it and it works, I guess you're good to go ;)

<fidel_>ngraves: I will ping Andrew, would feel bad just copypasting it

<nckx>ngraves: I think there are unresolved blind spots in the presence of grafts, but it's not nice that/if it actually says it's repairing something when it's not.

<ngraves>Yep, still struggling with it. What's weird is that I got rid of al my guix-home links in listed with guix gc --list-roots, deleted everything and rebuild it, I get the same errors. Should I make a bug report ? I probably can capture the output

<nckx>Sure.

<nckx>How did you ‘delete everything’? Using guix gc? Did you confirm that the old store items were actually deleted? I.e., that they are not live through some other/forgotten link(s)?

<apteryx>are people still able to 'gdb -p' on latest Linux-libre kernels?

<ngraves>yes, with guix gc. when I run guix gc --list-roots, I only have root guix-profiles with the bare-minimum (vim, make), guix-system profiles (but I fear to delete these -- if I can't even login anymore, it becomes tricky to even extract my data), /var/guix/gcroots/bootcfg, /run/booted-system and /var/guix/profiles and /run/current-system

<nckx>Yes, it's tricky. I certainly won't urge you to delete things you aren't 100% comfortable with, even if it could aid debugging.

<ngraves>Hum I will check that, there is possibly indeed broken links in system profiles

<apteryx>would someone know why adding debug symbols to the packages list of an operating system doesn't cause GDB_DEBUG_FILE_DIRECTORY to be set?

<ae_chep_>I am worried I have done something wrong with the ticket 59083. Could I ask someone to confirm? I was supposed to fix the commit message but I haven't heard from anyone since I did it

<nckx>Apart from using ‘git send-email -v1’ (or whatever git command you used) instead of ‘-v2’, I don't see anything wrong with how the patch was mailed.

<nckx>Content-wise, you still need to update the ‘revision’ along with the ‘commit’.

<nckx>(version (git-version "0" "1" commit)) is an upstream bug but also needs to be fixed. ‘"1"’ should be ‘revision’.

<nckx>Then, the patch title should be ‘gnu: bqn: Update to 0-1.66584ce1’ if I read that right. Double-check. Ditto for that line in the changelog.

<nckx>ae_chep_: I see the ‘revision’ point was raised in review but didn't make it into the second patch? Did you send what you meant to send?

<ae_chep_>It's not versioned right now :/ The devs frankly don't care much about versioning and don't see a value in it

<ae_chep_>So we're referring to commit hashes

<nckx>That's not what I mean.

<ae_chep_>Hang on, let me quickly catch up on what you've said

<ae_chep_>I am likely misunderstanding. Give me a second

<nckx>ACTION AFK, but I'll be back! 🤖

<gnucode>morning guix! Just a reminder, that you all are fabulous people. Especially nckx! civodul is pretty cool too!

<rekado>no route to host: 10.0.0.8

<rekado>that’s the aarch64 node that gives us eof

<rekado>according to the docs that’s pankow, so it’s not unexpected

<nckx>ae_chep_: Sorry to go half-Matrix on you and hide the meat behind a link, but here are the two changes I meant, hopefully explained more clearly: https://paste.debian.net/plainh/38e5dbfa

<nckx>ACTION is not fabulous, nckx is wearing shorts, nckx is very smelly, nckx just went running.

<nckx>But it's really the shorts that offend.

<ae_chep_>nckx: I think there are some basic things about git-email workflow that I don't know and understand so I want to take the opportunity to learn about the meat itself right now

<apteryx>re icecat timezones woes: post reboot, still affected, even with resistFingerprinting=false

<ae_chep_>I've saved the link and will check in a bit after I try to understand what I am doing

<nckx>The only thing you did ‘wrong’ there was specify -v1 instead of -v2. That's not automatic, so it's not like you could have done anything else.

<nckx>apteryx: What did you change since last time?

<nckx>I remember the consensus being: either make /etc/localtime a symlink, or explicitly set TZ=Your/Zone.

<nckx>ae_chep_: I don't know how you got that insane subject the first time, though :) Congrats.

<nckx>ae_chep_: Do note that the timeless wisdom in that link will expire in 24h.

<nckx>ae_chep_: It also doesn't discuss git. What, specifically, would you like to know more about that?

<apteryx>bah, qt applications don't work atop lightdm...

<apteryx>ACTION tries the last option, SDDM

<ae_chep_>nckx: not git, the email part

<ae_chep_>I think I'm a competent git user minus the emails

<ae_chep_>I don't understand what "-v2" did. I already had the `.patch` at hand. I think I could have just edited and sent that and I'm not sure what difference there would be

<apteryx>ah! opengl support is broken for my gfx card

<apteryx>glxgears displays gears that don't move ^^'

<nckx>ae_chep_: Yes, you could have edited it by hand. -v[0-9]+ is an argument to git send-email/format-patch that does it for you. With ‘git send-email’, there's not usually a .patch that hits the disc at all, or an edit step.

<nckx>Plus, if you're sending a 10-patch series, adding v2 by hand is a bit silly.

<ae_chep_>With emails, do we still have the concept of branches and a merge and can I think of this ticket as a merge-request?

<ae_chep_>That is how I'm thinking of it and I want to ammend existing commits in my _branch_

<nckx>You're sending patches. I don't see how you'd ‘merge’ patches.

<nckx>They are simply applied, usually on top of master, on a committer's machine, then pushed.

<ae_chep_>Okay yeah, we apply the diffs/patches

<nckx>There is no branch involved, that's entirely local to your choice of workflow, the only public artefact you produce are patches.

<apteryx_>OK, the OpenGL regression was caused by Linux 6

<apteryx>is anyone using nouveau with Guix System's latest linux-libre? Does it work for you?

<apteryx>(for 3D graphics -- OpenGL)

<ae_chep_>nckx: Ok. I think I have somewhat of a better understanding of what's happening

<nckx>ae_chep_: Not quite: please send all changes as an (in this case, single) patch, not a diff to your previous diff. In your case, I'll assume you have 2 commits now for this change. If so, you need to squash them together, then send that single patch.

<nckx>The changes themselves look good to me.

<unmatched-paren>ae_chep_: https://guix.gnu.org/manual/devel/en/html_node/Submitting-Patches.html#Submitting-Patches

<unmatched-paren>basically

<unmatched-paren>(afternoon, guix! :))

<nckx>The combined patch doesn't need to explicitly mention the revision; that's implied by the ‘Update to 0-2.66584ce’ that you'll use instead.

<nckx>I assume you've read the manual.

<apteryx>ACTION reported https://issues.guix.gnu.org/59361 (linux-libre 6 breaks OpenGL on nouveau driver). feedback from other nouveau users welcome!

<ae_chep_>nckx: okay when talking about patches I was going to ask if I should sum the patches or if they will be summed as they're going in

<ae_chep_>but I went ahead and added another commit. I'll combine them

<civodul>ACTION is an ancien user

<nckx>I think you might be expecting too much from the little cloud sitting in between you and the committer in the diagramme. It's just ‘send mail to’, nothing happens in between, and the committer should, ideally, just be able to ‘git am’ each mail you send as one commit and git push.

<nckx>There is no patch tracker or whatever that is summing or doing anything whatsoever to patches.

<ae_chep_>which means each ticket makes one single patch, and each new email I send for each ticket is the candidate for the final patch; they are not parts of a patch. I think I got it

<ae_chep_>Or so I'll continue to believe until I make another mistake

<unmatched-paren>ae_chep_: well, you *can* send multiple patches in one series

<unmatched-paren>(have a look at that manual page :))

<nckx>ae_chep_: Apart from the fact that Adam forgot (or didn't care :) to remove the ‘*** BLURB HERE ***’ place-holder, which would normally be a ‘Hello peeps this adds gemget’ cover letter, this is a good example of one patch series of 5 patches: https://issues.guix.gnu.org/59356

<ae_chep_>I apologise, really. I had read them all a while ago and when I didn't remember I didn't think to refreshen my memory and assumed the manual didn't have the information anyway

<nckx>So each mail is one patch is one commit, but one ‘ticket’ covers as many patches an you need.

<rekado>SAN downtime any moment now

<nckx>Aside, we use the term ‘bug number’ instead of ‘ticket’.

<ae_chep_>The "sending a patch series" manual actually had answers to some of my questions

<nckx>Heh.

<rekado>I’ll shut down ci.guix.gnu.org now

<nckx>OK, I was just going to ask about it.

<nckx>rekado: I assume it would look like a yanked cable to Linux?

<rekado>no idea

<nckx>Yeh let's not find out.

<nckx>ae_chep_: Don't forget my previous note on replacing ‘update to latest’, which we do not use.

<apteryx>where did 'M-x run-guile' go?

<apteryx>seems it was renamed to 'geiser-guile'

<unmatched-paren>apteryx: and run-geiser to just geiser

<PotentialUser-30>So: I startet the REPL with: guix repl , then did: ,import (gnu) + ,use (gnu packages gstreamer) + ,m gstreamer but HOW can i now inspect anything of the "contents" of gstreamer.scm, for example source, name, version, phases and so on in the repl loop

<ae_chep_>`gstreamer.<tab>` ?

<unmatched-paren>PotentialUser-30: (package-name PKG), (package-version PKG), etc

<unmatched-paren>phases would probably be (keyword-ref 'phases (package-arguments PKG))

<unmatched-paren>keyword-ref is from (oop goops)

<rekado>you can use ‘member’

<rekado>or match

<PotentialUser-30>ae_chep_: got no completions :-(

<PotentialUser-30>unmatched-paren: got warning: possibly unbound variable `package-name'

<unmatched-paren>PotentialUser-30: ah, you need to import (guix packages)

<ae_chep_>PotentialUser-30: I remember doing `(use-modules ((guix licenses) #:prefix ll))` and then autocompleting on `ll`

<unmatched-paren>ae_chep_: why? :)

<matta>I see ci.guix is down. Is this a scheduled maintenance thing? Seems I picked a fun morning to explore Guix (installed it on a Debian Stable) box. Without substitutes, Guix is now building libX11 in response to me typing "guix install hello", which is both amazing and pretty funny..

<ae_chep_>unmatched-paren: To be able to figure out what is available

<unmatched-paren>ae_chep_: Ah.

<PotentialUser-30>Did ,use (guix packages) and then (package-name gstreamer) -> i got: <unknown-location>: warning: possibly unbound variable `gstreamer' and ice-9/boot-9.scm:1685:16: In procedure raise-exception:

<unmatched-paren>PotentialUser-30: That's weird. Are you in ``guix repl''?

<PotentialUser-30>I think so - the prompt is: scheme@(gstreamer)>

<unmatched-paren>Oh, you did ,m gstreamer.

<unmatched-paren>You shouldn't do that.

<unmatched-paren>It'll move you to the nonexistent (gstreamer) module.

<unmatched-paren>(As you can see with that prompt)

<PotentialUser-30>OK. I start from scratch with LANG=C

<unmatched-paren>why use LANG=C?

<jackhill>matta: I don't know if it was planned or not, but the storage for it is down (I think managed by out hosts at MDC): https://logs.guix.gnu.org/guix/2022-11-18.log#170843

<ae_chep_>nckx: Okay true, I have fixed subject field as well

<jackhill>the other build farm at bordeaux.gnux.gnu.org seems to hava a substittue fro libx11 though. I guess the Debian package hasn't received the update that adds that to the default list.

<nckx>matta, jackhill: It was planned.

<nckx>That's why https://guix.gnu.org/ is still up this time.

<nckx>Next time there should be a banner or something there, but I didn't think of that until just now, and it being up at all is impressive progress.

<jackhill>matta: presumably you could do it by hand by editing the systemd unit to add https://bordeaux.guix.gnu.org to the substittue-urls for the daemon (or pass the --substitute-urls option to guix command invocations) and also do the required `guix archive --authorize` for the bordeaux key

<jackhill>nckx: haha, indeed, congrats

<PotentialUser-30>Thank you. It seems to work now - for future reference: I did now: ,import (gnu) + ,use (gnu packages gstreamer) + ,import (guix packages) then i could: (package-source gstreamer) and got $2 = #<origin "https://gstreamer.freedesktop.org/src/gstreamer/gstreamer-1.20.3.tar.xz ...

<jackhill>matta: or, you know, go for a walk and play with guix later :)

<nckx>I have nothing to do with that, to be clear.

<PotentialUser-30>unmatched-paren: part of the error messages were in german :-( So LANG=C is better for posting)

<unmatched-paren>PotentialUser-30: Ahh. :)

<civodul>great that we didn't lose the web site this time

<civodul>we're making progress :-)

<jackhill>speaking of guix weather, when it fails to connect to ci.guix.gnu.org, it bails out and doensn't continue on to check bordeaux. I guess I should file a bug?

<matta>jackhill: good advice! Not complaining here. I hadn't even run a 'sudo -i guix pull' yet after installing the Debian package.

<civodul>jackhill: looks like a bug worth reporting, yes (bonus point if you attach a patch :-))

<PotentialUser-30>ae_chep_: I think in "guix repl" there is no autocompletion ?

<ae_chep_>`(activate-readline)` . You will need to `(use-modules (ice-9 readline) (system repl common))`

<ae_chep_>You can put those in your `.guile` file

<apteryx>good news to IceCat users; gitlab should now be easier to work with soon: https://gitlab.com/gitlab-org/gitlab/-/issues/345328#note_1177668870

<PotentialUser-30>ae_chep_ it trows at the end: no code for module (ice-9 readline)

<old>Anyone has problem with magit recently?

<old>Installed from home profile: magit-status -> magit-menu-common-value is already defined as something else than a generic function

<ae_chep_>I don't remember what I did to make them available. Maybe a `guix install guile-readline` ?. Then they should work

<unmatched-paren>yup, guile-readline provides that module

<PotentialUser-30>guix package -I | grep readline gives now: guile-readline 3.0.7 ... but still the error: ice-9/boot-9.scm:1685:16: In procedure raise-exception: no code for module (ice-9 readline) hmm - perhaps i have to re-login cause i got a message regarding the profile

<PotentialUser-30>Cool. No more error after re-login. I'll try the readline thingy...

<unmatched-paren>PotentialUser-30: yup, if you don't your environment variables -- including GUILE_LOAD_PATH -- will not be changed

<PotentialUser-30>Now readline is working but gstreamer.<tab> gives no completions...

<ae_chep_>how did you import it again?

<ae_chep_>the prefix doesn't come with a period sign

<unmatched-paren>PotentialUser-30: gstreamer.FOO is not how you access fields

<unmatched-paren>it's (package-FOO gstreamer)

<dirtcastle>is guile fast when compiled?

<unmatched-paren>dirtcastle: sorta?

<unmatched-paren>it does do JIT

<dirtcastle>can u tell in multiples of c speed?

<unmatched-paren>nope, sorry

<unmatched-paren>it has a simple jit, apparently: https://www.gnu.org/software/guile/manual/html_node/Just_002dIn_002dTime-Native-Code.html

<dirtcastle>hmmm. i guess it depends on how efficient the code is?

<unmatched-paren>so not as complex/efficient as, say, the java or luajit compilers

<jackhill>civodul: :) I'll look and see what I can do. No promises though!

<ae_chep_>dirtcastle: What do you mean by "fast" and what's the task at hand?

<PotentialUser-30>Yes_: (package-FOO gstreamer) works

<ae_chep_>dirtcastle: I think bash is pretty fast for the operations I do with it even though for some computational problems it'll be outperformed by pretty much anything out there

<dirtcastle>I was wondering why guix updates are slow but that could be because of server speed not necessarily software.

<PotentialUser-30>Thanks for today. I would have no chance without this chat !!

<dirtcastle>I do aim to write scripts in guile. atleast in system and home configuration

<unmatched-paren>PotentialUser-30: No problem! :D

<PotentialUser-30>Wait - One more: (package-arguments gstreamer) gives $3 = (#:phases #<gexp gnu/packages/gstreamer.scm:481:11 7f938cf05d80>) How can i check these phases ? :-)

<unmatched-paren>PotentialUser-30: Ah, you'll probably just want to ``guix edit gstreamer'' to see them...

<PotentialUser-30>Yes - thanks - i know :-) But in case i'll try a derivation / variationi want to see the real situation !

<PotentialUser-30>*variation

<PotentialUser-30>Oooh ooh - guix is really a big big rabbit hole...

<rekado>a gexp is like an s-expression with package references

<unmatched-paren>ahh, you can do gexp->sexp, can't you?

<rekado>these references only make sense inside of a build context

<rekado>gexp->approximate-sexp

<unmatched-paren>Ah.

<rekado>because it’s really not equivalent

<dirtcastle>ae_chep_: I don't really have a good answer what do you mean by fast. I was wondering if guile was a good choice for guix and right now I'm only considering speed but I also consider other factors. anyways I'm too noob to make a decision. Imma keep using guix.

<dirtcastle>just now tried guix home import. what is this magic. mind blown truly.

<unmatched-paren>dirtcastle: guix home is great :)

<unmatched-paren> https://git.sr.ht/~unmatched-paren/conf/tree/root/item/home.scm behold.

<pkill9>nice home config

<pkill9>id like to make a tweak to the configurations that prepends a home directory for each program so it works with my launcher

<pkill9>then you could also do fancy stuff like configure multiple instances idk

<matta>I have https://bordeaux.guix.gnu.org/ up and running but 'guix pull' as root is failing to build /gnu/store/0iwmbss9qdlqz2ra22v7r76bhp1qfwrw-openssl-1.1.1f.drv. A test is failing: https://paste.debian.net/1261148. Is there a way to diagnose whether this is a problem specific to me?

<pkill9>also abstract allthe env vars into services that add them,e.g. a wayland servicethatsets allthe environment variablea for wayland

<pkill9>or maybe that's too much abstraction heh

<dirtcastle>unmatched-paren: sourcehut user :D. Thanks for the conf. there's lot to learn for me

<pkill9>there is so much possible configurationing that can be done

<dirtcastle>multiple instances of? pkill9

<pkill9>dirtcastle:ultiple instances of applications, or rather, multiple configurations

<unmatched-paren>pkill9: but how do you add all the wayland variables, when those variables are determined at compositor run-time

<pkill9>so you could add shortcuts that run emacs with one set of packages, and another shortcut that runs with another set of packagea

<unmatched-paren>WAYLAND_DISPLAY might be wayland-0, wayland-1, wayland-3.1412, wayland-dnalyaw...

<pkill9>or just different configuration files etc

<dirtcastle>pkill9: is this for applications like emacs while lets you input a config file in command line or for every app? does it achieve this using containers?

<unmatched-paren>pkill9: hmm, i think that might be possible by extending the emacs service

<Pineapples>greetings! does anyone else have problems reaching ci.guix.gnu.org?

<unmatched-paren>to support multiple differently named emacs servers

<pkill9>unmatched-paren: im talking about stuff like setting QT backend

<unmatched-paren>which is a thing with ``emacsclient -s server-name''

<unmatched-paren>pkill9: ah

<dirtcastle>guix pull - Savannah is being slow for me atm. don't think that's related to what you are asking. pineaple is asking

<matta>Pineapples: yes ci.guix.gnu.org is down for maintenance. See today's log. bordeaux.guix.gnu.org is a backup that is working.

<Pineapples>ahh I see... will switch to the backup, thanks!

<unmatched-paren>there's also nc kx's server guix.tobias.gr which i find to be quite helpful at times like these :)

<nckx>Joke's on you, I have a highlight for ‘tobias’.

<unmatched-paren>Gah, thwarted.

<nckx>& thanks for the praise!

<matta>Pineapples: let me know how that goes for you. bordeaux didn't have a substitute for openssl-1.1.1f, which "guix pull" wanted, and my local build of it failed (a test failure). I'm too much of a noob to diagnose further.

<nckx>It is literally a box in my house, so good to know it's serving the community.

<matta>nxkx: is there a way to list the available substitutes on a substitutes server? or query whether a particular substitute is available?

<unmatched-paren>matta: guix weather

<nckx>guix weather can query particular packages. There is no list.

<unmatched-paren>matta: specifically ``guix weather --substitute-urls=https://guix.tobias.gr''

<nckx>(It accepts --substitute-urls="https://… [https://…]"

<matta>is there a way to find a 'last known green' and pass that to "guix pull"? See my earlier question about not being able to build openssl due to a test failure. Seems that neither bordeaux or guix.tobias.gr has that built, which makes me suspect that it is broken for more than just me.

<nckx>In my case, that's probably just because I regular GC old packages.

<nckx>I would point you to the Cuirass (CI) Web interface for that, but… (…it is down).

<dirtcastle>Savannah was not slow. I had 2,600 commits :')

<nckx>cbaines: Is there a Web interface for bordeaux that can query built/failed packages?

<nckx>Why is that old (it is not in Guix master) openssl being built?

<matta>nckx: I don't know. I installed guix via the Debian Buster guix package, and now I'm running "guix pull". Maybe guix is building something old before it can build something new?

<matta>nckx: sorry, Debian Bullseye (11). So, the guix I'm bootstrapping from is old.

<nckx>I'm sorry I don't have a better answer.

<matta>no worries

<unmatched-paren>matta: maybe do ``command -v guix''

<nckx>Is it a time-related (expiry) test? Those are known time-bombs, and kind of break the promises Guix makes.

<unmatched-paren>yeah, i think that is the issue

<unmatched-paren>expired certificates used with the tests

<nckx>We ‘work around’ it by never deleting substitutes, but, erps.

<nckx>Serious silly suggestion: set your system time back, if you dare. (Better not run too much other software in the interim, it might get confused.)

<unmatched-paren>is there some way the build containers could set the time to 1970-01-01?

<matta>"guix describe" tells me "hint: Perhaps this `guix' command was not obtained with `guix pull'? Its version string is 1.2.0."

<matta>"guix" is /usr/bin/guix, which looks like it is using the system (Debian) installed guix to bootstrap itself. Having never completed a "guix pull" it can't.

<pkill9>what does normalize-package do?

<unmatched-paren>matta: ah, yeah, maybe remove the apt-installed guix

<nckx>You would think so, but it's not actually trivial. Although that's usually discussed in the context of reproducible builds. Maybe something like faketime would just about suffice for openssl. Still, it would be ad hoc, not something you could enable globally without breaking other things.

<matta>I think I'd have no guix at all at that point. :)

<unmatched-paren>pkill9: the packages field accepts a list of ((PKG OUTPUT) ...)

<unmatched-paren>it simply changes PKG to (PKG "out")

<unmatched-paren>matta: hmm, yeah

<matta>I wonder if I could download guix 1.3 from https://guix.gnu.org/manual/en/html_node/Binary-Installation.html and use that to install 1.3 over my 1.2?

<unmatched-paren>i guess you should just set back the system time

<nckx>Oh, I missed the ‘1.2.0’ message.

<nckx>Then you should try guix-install.sh.

<matta>nckx: not a bad idea. Though I think this will self heal once ci comes back and the substitute becomes available?

<nckx>I cannot guarantee it but I think so.

<florhizome[m]>issues.guix.gnu.org is down, too?

<nckx>Yes.

<nckx>ci.guix, issues.guix… I think that's it?

<nckx>florhizome[m]: Use https://debbugs.gnu.org/cgi/pkgreport.cgi?package=guix-patches (or =guix) for now.

<rekado>ACTION powers on ci.guix.gnu.org

<florhizome[m]>Ok. Maybe someone wants to take a look at https://debbugs.gnu.org/cgi/bugreport.cgi?bug=58501 ?

<florhizome[m]>At least two of these packages I find pretty useful

<florhizome[m]>power–profiles–daemon and iio–sensor–proxy

<florhizome[m]>Or this 😇 https://debbugs.gnu.org/cgi/bugreport.cgi?bug=59105

<rekado>ci is back up

<rekado>and so is issues.*

<rekado>+ debbugs sync

<nckx>civodul, rekado: Thanks!

<nckx>rekado: This masked a firmware update, too, right?

<matta>Yep, guix was able to grab https://ci.guix.gnu.org/nar/lzip/dkzivzn17qilmqdfpyps62b395wxhshh-openssl-1.1.1f (which no longer builds due to the suspected certificate expiration issue) so I'm unblocked.

<Pineapples>rekado: Amazing, thanks for the update! matta: I also had some issues with the backup, but things seem to be working now with the ci.

<rekado>nckx: I tried to have an update for the RAID controller applied, but this failed.

<rekado>nckx: there have been firmware updates to all of the disks in the SAN, which is what took most of the time

<rekado>the controller reset also fixed a configuration problem that affected our server

<rekado>(two links in the same failover domain, which would have been bad)

<rekado>we can take care of the PERC update on the next reboot (when we switch to multipath)

<nckx><two links in the same failover domain> But that still requires multipath, or not?

<nckx>Or is that close now?

<florhizome[m]>Currently one package of mine fails in the “validate run path” phase because one dependency can’t be found in RUNPATH 🤔

<florhizome[m]>Don’t really know what to do with dad

<apteryx>nckx: icecat 91 processed timezones correctly for me, when resistFingerprinting=false (everytimezone.com)

<apteryx>after moving to 102.3.0-guix0-preview1 out /gnu/store/4gph2kbnmy64ii0fs9msig2jzjsnxdxi-icecat-102.3.0-guix0-preview1 it stopped

<a12l>Is there something special with `guix repl` (automatically loaded modules etc.), or is it pretty much the same as running the usual guile REPL?

<apteryx>this one works, from early september: icecat 91.13.0-guix0-preview1 out /gnu/store/bzpyas70s9j95dqad00vafks5icg51dm-icecat-91.13.0-guix0-preview1

<nckx> https://logs.guix.gnu.org/2022-11-14.log#221525

<nckx>I didn't follow the conversation after that day.

<nckx>a12l: See the opening paragraph manual section of ‘guix repl’.

<nckx>*of the

<a12l>nckx: Ah, thanks! Forgot to check the ref manual

<a12l>nckx: No problem regarding the previous discussion! I get error messages when I try to rebuild my home config, but when I realized that it actually successfully built my config.

<nckx>Ah?

<a12l> https://github.com/foo-dogsquared/nix-overlay-guix/issues/8

<cbaines>nckx, to answer your earlier question, data.guix.gnu.org (or data.qa.guix.gnu.org) is the place to go to for build information

<zamfofex>apteryx: I was able to get timezones working in IceCat by invoking it as ‘TZ=… icecat’

<nckx>cbaines: Thanks! I don't know how to use it to, say, ‘give me the latest successful openssl build’.

<nckx>I'm probably missing the obvious. I'm just used to ci.guix.

<apteryx>zamfofex: which version are you using?

<apteryx>which TZ value? doesn't work with the ones I've tried

<zamfofex>It says ‘102.4.0esr (64-bit)’

<cbaines>nckx, if you go to data.guix.gnu.org, to the master branch, then click latest processed revision, then search for the package in question, you can see the history of builds for that package

<nckx>TZ=Europe/Brussels worked for me, then.

<nckx>cbaines: Ohh… my mistake was going straight to ‘Jobs’.

<apteryx>I'm currently using GNU IceCat 102.5.0esr

<zamfofex>apteryx: Though I can confirm it worked transparently (without ‘TZ=’) before.

<apteryx>nckx: could it be because Brussels is in the same timezone as UTC?

<nckx>It's… not?

<nckx>Never is.

<apteryx>ok :-)

<zamfofex>(And I had to go out of my way to investifate how to fix it.)

<rekado>nckx: yes, to be affected by this configuration problem we would have had to actually use multipath.

<nckx>It's currently UTC+1.

<cbaines>right, jobs relates to the Guix Data Service loading information

<nckx>Summer +2.

<nckx>rekado: Got it.

<cbaines>nckx, here's a page that lists openssl outputs along with build information https://data.guix.gnu.org/repository/1/branch/master/package/openssl/output-history

<zamfofex>apteryx: Note that if you launch IceCat without fully closing it before, it won’t actually create a new process, it’ll just open a new window in the existing process.

<apteryx>right, I think you need 'icecat --new-profile' if you want multiple processes

<nckx>cbaines: Thanks again. I didn't get there because the ‘master → latest revision → package → history’ path wasn't logical to me, but I want to stress that it's just a lack of familiarity. Cuirass isn't exactly intuitive to me either.

<apteryx>nckx: funny, it works with TZ=Europe/Brussels

<cbaines>nckx, still, it's something to do better at

<cbaines>hpc.guix.info actually links to these pages

<nckx>apteryx: …

<cbaines>maybe we can get the packages.guix.gnu.org thing to do similarly, once that's online

<nckx>You need to move.

<apteryx>zamfofex: but perhaps it was that, it works now with TZ=America/Montreal hmm.

<zamfofex> https://repology.org/repository/gnuguix https://usercontent.irccloud-cdn.com/file/iaWkozLr/image.png

<zamfofex>😮

<nckx>Heh.

<nckx> https://repology.org/graph/repo/gnuguix/projects_outdated.svg

<nckx>(Misleading Y-axis, but still.)

<apteryx>is the front page of repology reflecting these new numbers yet?

<apteryx>(the projects ranking in terms of sheer numbers)

<nckx>Shadow side (but Repology has a lot of questionable definitions, this is likely one of them): https://repology.org/graph/repo/gnuguix/projects_problematic.svg

<nckx>apteryx: Yes.

<nckx> https://repology.org/graph/repo/gnuguix/projects_total.svg and front page says ‘GNU Guix - 19529’ total projects.

<apteryx>ah, "projects"

<zamfofex>How does Nix have 80k “packaged projects”? (And can we get that too?)

<nckx>Sigh.

<nckx>Because it's Nix?

<nckx>:)

<zamfofex>“Just run ‘guix import nix all’!”

<nckx>There is significant duplication in that number, and a *lot* of automation, which is good (why yes, we have rust-elonmusk-memecoin ready to install!) and bad (it's broken beyond repair, but it built!).

<nckx>And of course they package binaries.

<nckx>* ‘package’

<nckx>You're just measuring very different things, which is fine. Repology encourages comparing them, which is not.

<nckx>ACTION meant nixpks.rustPackages.rust161.elonMusk.memeCoin of course.

<apteryx>where are kernel issues reported? I they have something easier to track than the linux-kernel mailing list

<zamfofex>I was mostly joking. Though it makes me wonder how they count “packaged projects”. Like, does every Rust crate and npmpackage count as a different project, or must they be explicitly registered?

<rekado>should the thousands of automatically imported CRAN packages count to our total? https://github.com/guix-science/guix-cran

<nckx>They have bugzilla, apteryx.

<apteryx>good to know!

<nckx>rekado: For a week, during the 1.4 release, so lazy distro reviews pick it up. Then remove them again.

<rekado>or the 5306 melpa packages? https://github.com/babariviere/guix-emacs

<zamfofex>Now I have a question: Is there any reason to include those packages in Guix itself? Like, I don’t mean all of them, but I feel like it might make sense to *only include* the ones that require some kind of patch or change to fix builds, then direct people to those kinds of automated repositories for the rest (making sure those repositories use the fixed dependencies packaged in Guix, and also providing substitutes).

<zamfofex>I feel like it might make more sense than to actually have to explicitly package them in Guix itself, which is time‐consuming and requires a lot of manual effort.

<zamfofex>I’unno, I suppose maybe I’m just dumb.

<mekeor[m]>maybe there could be some official auto-generated, experimental channels

<mekeor[m]>has there been a discussion to move the docs from texinfo to org-mode?

<unmatched-paren>mekeor[m]: unlikely to happen

<mekeor[m]>unmatched-paren: why? because org is less expressive?

<unmatched-paren>because texinfo is the official gnu documentation system

<unmatched-paren>and because i don't think there's a way to translate org

<unmatched-paren>we use po4a to translate our texinfo docs

<tricon>mekeor[m]: what's the issue with them being in texinfo?

<mekeor[m]>unmatched-paren: org comes with a function to export texi

<mekeor[m]>tricon: i'm not used to texinfo and its syntax does not look nice

<mekeor[m]>:D

<nckx>OK, but that ‘argument’ applies equally to Org mode.

<nckx>It's a pain to edit, and I'm not used to doing so.

<nckx>😛

<mekeor[m]>nckx: why a pain to edit? :)

<nckx>(Better ones are: it confuses structure with presentation, and was optimised for note-taking, not documenting software, and it shows.)

<nckx>mekeor[m]: At least in Emacs, editing Org is an ordeal. Magical shortcuts, text that doesn't do what it should, etc. You have to turn off org-mode to make it useful.

<mekeor[m]>big take :D

<nckx>I'm being provocative but I'm not joking.

<nckx>Org's pitch is ‘so you've chosen to convert to Orgism, welcome new acolyte’. For everyone not interested in just getting something done, that is not an interesting pitch.

<nckx>s/not// — heh.

<nckx>Anyway, this isn't going anywhere productive, my bad. If there's a better case for Org mode than ‘I already know and like it’, it can be made.

<mekeor[m]>i did not understand what you said but i agree that my argument was not strong at all and very subjective.

<mekeor[m]>do i see correctly, that the whole manual is written in one single .texi file?

<nckx>Yep.

<mekeor[m]>well, at least that could be improved

<tricon>personally, i have to, as usual, agree with nckx. i'm a big org-mode user, but it's not fit for structured documentation, imho.

<nckx>Welcome, new acolyte.

<tricon>haha!

<tricon>nckx Acolytes: How it started: 👨‍💻 / How it's going: 🧙‍♂️

<nckx>Speaking of weird cults and feelings of belonging: this is your every-so-often arbitrary reminder that guix/something/you cloaks are available, for those who know what those are, and care.

<nckx>These reminders are in no way related to me seeing civodul join, the only owner of one.

<unmatched-paren>mekeor[m], nckx: At least two .texi files, actually.

<unmatched-paren>guix.texi and contributing.texi.

<unmatched-paren>not sure why the latter was split out.

<nckx>O u r right of course.

<mekeor[m]>would you agree that a texi file with 43318 loc is not nice? actually, it feels fine to navigate with emacs. im surprised

<nckx>I don't know either, and yet it makes some weird intuitive sense in that I both knew that and still thought of guix.texi as ‘the entire manual’. For no rational reason.

<unmatched-paren>i think if we're going to deal with overly-long source files, crates-io.scm should be the first target :)

<unmatched-paren>it slows down emacs considerably

<nckx>mekeor[m]: Honestly, no, I don't agree, if you're explicitly asking. I think it's fine and a single file is easier to edit and search than multiple files. But the alarm in my bike shed is going off, BRB.

<civodul>so, this is embarrassing: according to /var/log/messages, *something* causes NetworkManager to invoke "herd status nscd" and "herd restart nscd", but i can't see where this comes from

<unmatched-paren>wait, is this a "bikeshedding" joke or is your bike shed alarm actually going off?

<civodul>any idea?

<nckx>unmatched-paren: The former.

<unmatched-paren>O. K.

<nckx>Feeling like I'm being unpleasantly grumpy makes me genuinely uncomfortable (something I need to work on) and being uncomfortable makes me make bad jokes.

<dlowe>So I'm trying to hack on a package (tcl) and fix the way it handles search paths. I can't seem to figure out how to test it.

<dlowe>I've tried ./pre-inst-env guix shell tcl --search-paths but it just gives me the PATH and not TCLLIBPATH

<unmatched-paren>dlowe: perhaps it's because you don't have any tcl libraries installed?

<unmatched-paren>maybe try ``./pre-inst-env guix shell tcl tcllib --search-paths''

<dlowe>I want to say I tried that too but maybe not

<dlowe>The other issue is that it seems like tcl packages will run tcl and query for the location that they're supposed to install in.

<dlowe>This location, on guix, ends up inside the tcl store

<unmatched-paren>hm

<dlowe>so I have no clue they're working right now

<unmatched-paren>i guess you could patch tcl?

<dlowe>yeah, but they're working :D

<dlowe>so I don't really understand how the installation process works, I guess. Maybe that sort of thing is stripped automatically?

<dlowe>Maybe it's just a mismatch. tcl will search for subdirectories already, so I was thinking if all the packages install in lib/tcl8.6 then tcl will find them

<mekeor[m]>unmatched-paren: here's the list of the longest text files in the guix repository: https://paste.rs/BAQ

<civodul>ACTION found it: openresolv restart nscd

<nckx>civodul: openresolv.

<nckx>Ah, there's even a patch!

<nckx>So that explains that.

<rekado>mekeor[m]: I see nothing wrong with a big texi file. Can popular editors only deal with short files now?

<rekado>(there are more external fragments that are included in that texi file, but I feel that this is about some sort of principle and not reality)

<nckx>civodul: I totally missed your message 😃

<apteryx>ACTION tries a mesa rebuild to see if the graphic issue resolves for nouveau on linux 6

<civodul>nckx: heh :-) that thing was a mystery for me

<civodul> https://repology.org/repository/gnuguix

<civodul>notice the effect of Russia unblocking today :-)

<apteryx>only one thing is stable, the number of maintainers

<lechner>that's funny

<nckx>Oh, I missed this one earlier: https://repology.org/graph/repo/gnuguix/problems.svg . I wonder what the difference is with https://repology.org/graph/repo/gnuguix/projects_problematic.svg .

<nckx>Anyway, we have offloaded our problems to upstream, so that's good.

<rekado>I think it’s somewhat negligent to host a comparison website like that and *not* display that the data are known to be wrong

<nckx>Sigh 2.

<lechner>nckx / thanks for the cloak offer. for now, i am happy with mine but what's the process to apply for a guix one, please?

<nckx>Uh. Hm, what did I decide again…

<nckx>You ask me. Something something. Then we discuss pricing. Then you get cloakings.

<nckx>No, it was something like having a handful or more contributions over a reasonably stable period of time.

<lechner>nckx / thanks!

<nckx>But /user/ cloaks are easy. /user/ cloaks is you saying ‘I use Guix’ me saying ‘yes that is very plausible why would anyone not use Guix’ and then you get cloakings.

<unmatched-paren>night guix!

<nckx>o/

<nckx>ACTION mirrors openssl@1.1.1f substitutes…