IRC channel logs

<Fare>Hi. I'm trying to build cryptsetup-static-2.3.7 on arm64, and its ./configure fails with: configure: error: You need the gcrypt library.

<Fare>how do I even start to fix that?

<Fare>ACTION tries to update his channels-lock.scm and pray

<oriansj>You know something is missing if praying is required when using a declarative package manager.

<oriansj>perhaps guix needs a bugs tool

<oriansj>with perhaps a way to collect and report on which versions work and which don't (possibly on which architectures)

<Fare>Often, upgrading the channels solve an issue, and introduces another :-/

<Fare>I love Guix so much in theory, but in practice, it's so much harder to use than NixOS, despite the better language.

<Fare>Updating the channels didn't help :-(

<Fare>How do I report it?

<AwesomeAdam54321>Fare: You can email bug-guix@gnu.org

<|F9|>Fare: I loved guix, but it's too slow

<|F9|>I am not sure, maybe it's my side problem.

<|F9|>But 5-6 minutes to install little package?!

<|F9|>Like (random system just to compare) on FreeBSD it would take 7 seconds

<Fare>|F9|, you need to add substituters

<|F9|>who

<|F9|>Anyway, you all can dislike me now

<|F9|>cause I use OS X

<|F9|>non-free os

<Fare> https://substitutes.nonguix.org

<Fare>Nix runs on OS X... though as of late, the installation isn't seamless anymore.

<|F9|>Thanks for link, I may try

<HiltonChain[m]>|F9|: https://guix.gnu.org/en/manual/devel/en/html_node/Substitutes.html

<|F9|>A bit offtopic, but overall, how bad is OS X?

<|F9|>'s/bad/evil/'

<Fare>I think the one that was missing from my config might have been bordeaux.guix.gnu.org

<Fare>|F9|, evil enough. But they have the fastest / lowest power hardware.

<|F9|>Yeah, just OS X is so easy and simple to use, it's just working.

<|F9|>You don't have to spend 10 hours to learn it

<Fare>You just have to work 20 extra hours to afford it.

<Fare>and then become Apple's bitch.

<littleme[m]>👻oh yeah, and you became a small part of dear osx, rm -rf money_pride_control

<littleme[m]>and ifconfig lots of unknow interface 🐑 hope nix at osx save your soul.

<littleme[m]>Maybe you will feel pride about yourself that you can afford double even tripple price to use a machine that just work like others. 👻 dear, and the software actually suck if there is no electron-tech

<littleme[m]>unless you choice M1, it's not cheap, at least it show the design of good power manage to CPU.

<|F9|>Fare yeah apple stuff is very expensive

<|F9|>littleme[m] even considering I hate apple pretty much...

<|F9|>Nobody in the world makes so great quality hardware like they.

<|F9|>like, software, it's great, but non-free, so it makes it bad.

<|F9|>But hardware, it's awesome.

<|F9|>and like.

<|F9|>I always can install some Trisquel or FreeBSD or even 9front to macbook

<littleme[m]>nope, 👻it's not such pretty without m1, it stuck so long. there is Thinkpad X1,dell xps, so much choice now. it did guide the design before, but not today

<|F9|>littleme[m] do you know what design is?

<|F9|>I know what design is, that's why I choose apple's hardware.

<|F9|>Also you can libreboot macbook

<|F9|>And (old ones) use open firmware

<littleme[m]>the only attractive part is the m1

<littleme[m]>if guix could run on it, i'll buy it

<|F9|>I was talking about case, screens, etc.

<|F9|>Yes, old hardware is slow, but it's great.

<|F9|>And you can run free software on it.

<|F9|>Which is amazing

<littleme[m]>i need a stuff that could manage power well

<|F9|>Saying that even though I dislike GNU/Linux a lot and slowly purging it everywhere.

<littleme[m]>screens 😂 it's 2023 today, you can't find a worse screen with a mac-price-level

<|F9|>good luck lol.

<|F9|>example

<|F9|>powerbook g4 vs any of my laptops and any of my monitors

<|F9|>powerbook g4 better.

<|F9|>Made in 2004..

<|F9|>I will able to test ThinkPad X1 Gen 5 today

<|F9|>So I will compare.

<littleme[m]>👻it's such cheap 👻👻👻 i got X1 Gen 3 at 300$, come on 👻.

<|F9|>Don't use so much emojies, it looks silly.

<|F9|>300 usd is cheap?

<|F9|>Seriously?

<littleme[m]>😜i'm

<|F9|>Congrats if you are rich, but not everyone are.

<Fare>|F9| if you can't get the top of this year... you can still get the top of a few years back.

<littleme[m]>mac is even worse, the m1 require 1000$🥲

<|F9|>Was I talking about m1?

<littleme[m]>maybe price is different between our place

<littleme[m]>👻i do compare it to m1,lol

<|F9|>Don't compare what can't be compared.

<|F9|>All I know about X1 is that it have shitty design, and people say it's great overall (apart from design and chinese keyboard)

<littleme[m]>but i failed to configure the audio driver at Guix in X1, but i hardly play sound

<|F9|>do it have good sound?

<littleme[m]>indeed, i'm chinese lol i love it

<littleme[m]>🕶️, i don't know, i can't diff it

<Fare>$1000 is so low compared to what machines used to cost back in the day... and that's not even accounting for all the inflation!

<|F9|>I'm audiophile, sound is very important to me.

<|F9|>Fare yeah

<|F9|>Unless you live in Ukraine like I do

<|F9|>And you have 57 usd per month free to use

<|F9|>lol

<|F9|>Also, about software, it mostly shit everywhere.

<littleme[m]>🥲

<|F9|>Windows is unusable garbage, GNU/Linux is usable but still overbloated garbage

<Fare>The ruscists destroyed the museum of computing in Mariupol. I can't forgive that.

<|F9|>Awful.

<|F9|>I got explosion 500 meters away from me

<|F9|>They reached kids clinic

<|F9|>People died there.

<VesselWave>Is there a way to install mu4e as a guix package? Or how get it the guix way?

<VesselWave>Oh, sorry. It comes with mu

<jpoiret>hi guix

<user_oreloznog>hello guix!

<futurile>happy weekend Guixers

<davidl_>futurile: Happy weekend!

<davidl_>what is required for a package's info file to be installed correctly when you make a package using the gnu-build-system?

<janneke>jpoiret, civodul: i managed to build "hello" natively!

<futurile>davidl_: are you sure it's not being 'installed' (copied to the right location), versus your profile not finding it? AFAIK if the underlying 'make install' command works then the docs/info should be installed correctly

<janneke>civodul: you asked about all the new failing coreutils tests on the hurd and debian

<janneke>i didn't find patches or anything before, but i just found how they do it

<janneke>in coreutils's debian/rules there is:

<janneke>override_dh_auto_test:

<janneke> # tests fail a lot on the buildds

<janneke>it seems debian just skips all coreutils tests on all platforms, iirtc

<janneke>ACTION built coreutils on debian-hurd using dpkg tools and found it went from 'build' straight into 'install'

<janneke>so yeah...

<civodul>janneke: ah, good to know! :-)

<civodul>these are failures of the Gnulib tests i guess?

<civodul>these are very picky

<civodul>to some extent it's good because it avoids discovering problems down the road

<civodul>OTOH, they're sometimes too picky, like testing things that aren't mandated by the interfaces

<janneke>civodul: there are still 6 gnulib tests that fail (one less), but no, all new failures are coreutils' own tests

<janneke>civodul: i haven't looked into the test suite, i would hope that they have basic tests, and then picky ones

<janneke>ACTION wonders if such feedback ever reaches upstream: your tests don't work for us, we turn them off

<davidl_>futurile: basically, Im writing a Makefile right now for one of my own projects, trying to make things work as smoothly as possible with Guix' gnu-build-system. I am new to using make though, so Im not sure how .info files are normally handled.

<davidl_>I have a build directory where I put all files, like build/bin, build/share/project, build/share/info, I just wonder how things are handled with info files so I can avoid trial and error with it.

<lilyp>unless you have a good reason not to, I'd suggest using autotools

<janneke>ACTION pushes a (their) wip-hurd branch with the two pending patch sets (that need some cosmetic changes) and the to-be-sent commencement one, and some goodies

<jpoiret>janneke: nice work!

<janneke>jpoiret: thanks!

<jpoiret>i've been derailed by misc stuff this morning (wanted to upgrade b4, but it has a new dep that needs to be upgraded, and it doesn't generate its own doc)

<janneke>oh, bah ;)

<janneke>i'll be afk prolly till tomorrow in a few

<jpoiret>what do I do with patches that overall solve something, but have a bunch of mistakes that I fixed locally? should I just push them with all my changes?

<jpoiret>janneke: are you using the new tagged mig btw?

<janneke>jpoiret: yes

<jpoiret>I haven't followed too closely, my own local branch has it

<janneke>great, then we should have the same

<jpoiret>if gnulib's tests fail, won't we have problems down the line with other packages using gnulib?

<janneke>i'll prepare a 'commencement update / native build hello' patch set from wip-hurd once both our pending patch sets are pushed

<janneke>that could be, but goes on a package-by-package basis, i guess

<janneke>"<jpoiret> what do I do with patches" -- i don't get what you're saying, are those patches with mistakes already pushed?

<jpoiret>nope

<janneke>ah, ok

<jpoiret>i was wondering if it was fine to push heavily modified patches under the original author's name, since you've changed their patch quite a lot

<janneke>if the mistakes are obvious/trivial, no need to send another review round, i would guess

<janneke>if i change anything more than cosmetics (it's not black and white), i usually add a co-authored-by

<janneke>jpoiret: feel free to revert + push-changed any commits to wip-hurd

<janneke>(or reset the branch entirely, preferrably with a heads-up notice)

<jpoiret>yeah, I'm wary of adding new branches because I like rewriting the history, don't know how to handle that very well when other people are also using it

<janneke>ACTION does that a lot too

<janneke>yeah, it can get tricky if you don't align

<janneke>i usually keep adding squash! commits until we agree to squash them all, and reset

<davidl_>lilyp: ok thanks for the suggestion. My projects are not C. They are mainly bash and python projects, but still for at least Bash it might be useful. I just want to make it into an easy and standard build process.

<ChocolettePalett>You could look how they do it in other projects, but I can't remember any project that uses info files

<jpoiret>ChocolettePalett: do you mean info manuals?

<ChocolettePalett>I guess davidl_ meant it

<jpoiret>lots of projects use info manuals, I suggest checking out your `info` do have a look at some examples

<jpoiret>they're less popular then man pages for sure though

<lilyp>davidl_ for python, prefer the pep-whatever build systems, there are some useful ones in guix

<lilyp>(assuming python is the only language in the repo)

<dthompson>jpoiret: I totally missed your question yesterday. I was having issues where a guix pack binary wasn't running correctly because it couldn't find glibc locales. I was able to solve this problem by using a wrapper script that set GUIX_LOCPATH appropriately.

<jpoiret>ah, nice

<Guest6725>afternoon, guix :)

<jpoiret>petition to add forceinbodyfrom=true to our git config

<spacecadet[m]>Hello guix, I'm in the unfortunate situation of needing to run guix shell inside a guix system vm. Even if I wanted to give the vm r/w access to the store (I wouldn't) I don't think that's possible to do safely. Does anyone know a workaround here?

<civodul>spacecadet[m]: hi! you could use a full-blown VM image ("guix system image -t qcow2"), and there you could run guix-daemon and all

<civodul>heavy-handed, but works

<spacecadet[m]>civodul: that works, but does add a huge overhead

<davidl_>lilyp: python isn't the only one in the repo's :-) I did however, find someone combining autotools and python's setuptools https://blog.kevin-brown.com/programming/2014/09/24/combining-autotools-and-setuptools.html

<davidl_>ChocolettePalett: me neither, other than that I know that with guix I can use info guix :-) I checked it out but didn't find it informative. I eventually just looked at the gnu-build-system in the guix source, and I think it'll work out fine if I just have a make install phase that installs some info files to /usr/local/share/info, however, it remains to be seen! I will just have to do trial and error soon.

<lilyp>whatever you do, just make sure to honour $prefix and you ought to be fine

<davidl_>yeah seems like it. Ill probably do a preliminary regular configure and Makefile scripts before sswitching to configure.ac and Makefile.am

<VesselWave>Hi! How to send a guix patch with mu4e the most efficient way?

<TheSkylarverncc[>how do i make a file defined by plain-file executable

<VesselWave>chmod +x filename

<TheSkylarverncc[>read-only file system

<VesselWave>TheSkylarverncc[: What file do you want to modify?

<TheSkylarverncc[>a file i defined in my guix home configuration

<TheSkylarverncc[>with home-files-service-type

<jpoiret>guix records are a ticking time-bomb

<VesselWave>TheSkylarverncc[: Change local-file to computed-file https://guix.gnu.org/manual/devel/en/guix.html#index-computed_002dfile

<patrickt>Hello, sorry if this was already asked and addressed (that last few days have been pretty draining). Trying to set up Guix on a new system but the 1.4.0 installer keeps failing with 3 different internet connections. I ran guix pull in command line, which reported back guix pull: error: Git error: the SSL cetificate is invalid. Help is immensely appreciated. I am also eager to help make the installer more streamlined (would be nice if it could

<patrickt>automate more of the disk partitioning stuff)

<patrickt>By failing, I mean, it says the substitutes servers are inaccessible

<VesselWave>TheSkylarverncc[: Sorry I haven't really used guix home

<VesselWave>TheSkylarverncc[: plain-file reqiures string, computed-file requires gexp. I don't know how to make gexp that outputs string

<evilsetg[m]>pjt[m]: Is the system time correct?

<patrickt>evilsetg: Ah snap, good catch, thank you so much for your help!

<evilsetg[m]>You're welcome :)

<mekeor[m]>VesselWave: i do this: having git-email.el installed (from my maintained fork which incorporated submitted patches: <https://codeberg.org/mekeor/git-email>), in a magit-status buffer, type "W c s". this is my config: https://paste.rs/MHBMq.el

<mekeor[m]>note that you need to have required the -mu4e feature

<mekeor[m]>i did not try it with multi-patches

<mekeor[m]>btw, when you want to apply patches from an email with mu4e, i recommend: (add-to-list 'mu4e-view-actions '("apply git patch" . mu4e-action-git-apply-mbox))

<civodul>jpoiret: "guix records are a ticking time-bomb", what makes you say so?

<civodul>(i can see ticking time bombs in Guix, but not this one :-))

<jpoiret>civodul: the macro foo is bound to blow up in our faces (the match-record patchset is one example)

<jpoiret>see #guile for me desperately trying to debug a related problem

<jpoiret>i don't know how many people understand how guix records work, but i don't expect it to be more than a handful

<patched[m]>Hey, irc logs since january don't seem indexed, so I'm asking again...

<patched[m]>How can I make libstdc++ available in guix shell?

<civodul>jpoiret: aaah, i see what you mean :-)

<jpoiret>patched[m]: add `-e '(list (@ (gnu packages commencement) gcc-final) "lib")'`

<civodul>it's heavy-handed macrology, and it's become hairy

<jpoiret>yes, especially if we want better error-reporting

<civodul>for that we should look at the other syntax-* that Racket has, perhaps

<civodul>forgot what it's called

<civodul>not "rules", not "case", hmm

<civodul>syntax-parse!

<jpoiret>i'm thinking that we should drop "records: match-record: Display more helpful field-not-found error."

<civodul>ok

<jpoiret>that's the source of the (current) problems of the patchset, the rest LGTM

<mekeor[m]>patched: wildly guessing, try "gcc-toolchain:static" xD

<civodul>i thought the patch set was mostly ready?

<jpoiret>no, that code causes `gnu/services/networking.scm` to not compile anymore

<jpoiret>because match-record is used with a body with an ellipsis in it

<civodul>we're talking about https://issues.guix.gnu.org/63135 right?

<jpoiret>yes

<civodul>ah

<civodul>damnit

<civodul>so we need to investigate what you posted in #guile

<civodul>what's the urgency?

<jpoiret>even from a very close inspection no one could've guessed that this would bite. and i was about to push it!

<jpoiret>none, we can add that later

<patched[m]>It's not in gcc-toolchain :^} I used gcc before the last core update, when it was removed

<civodul>ok

<jpoiret>i can push the patchset without that offending one

<mekeor[m]>ACTION wonders if the libera-matrix bridges works again

<mekeor[m]>patched: did you try the "static" output?

<jpoiret>mekeor[m] patched[m]: can you read our messages?

<civodul>in "records: match-record: Display more helpful field-not-found error.", the #,s bit at the bottom looks suspicious to me

<jpoiret>no, here you want to insert the whole expression, and it's not bound by syntax-case/rules

<VesselWave>mekeor[m]: Thank you so much! What patches are you appllied to your git-email fork, why I should use it?

<jpoiret>i reduced the bug to the MWE i sent in #guile, which i think is a guile bug i think

<jpoiret>(here's me repeating things in the same message, not looking good)

<civodul>:-)

<jpoiret>civodul: I just thought I'd have a go at that patchset today while pushing some other stuff because it's been hanging around for a while.

<civodul>yes, much appreciated

<jpoiret>but yeah, I don't think there's any rush to get that working

<civodul>if dropping that one patch works, you can do that

<patched[m]>I have tried all the outputs. That's why I went to the chat last time I asked here

<jpoiret>i'll need to modify the next patches but yeah, it'll work

<jpoiret>VesselWave: the matrix-irc bridge is down

<VesselWave>I've never heard that guix irc is bridged with matrix, lol

<jpoiret>civodul: https://paste.debian.net/1281908/

<jpoiret>VesselWave: people with the [m] are on matrix

<jpoiret>the bridge has been having issues for the past few weeks

<jpoiret>civodul: i think the workaround of making it syntax->datum then back when raising the error will work, but it's quite ugly

<jpoiret>okay, I have it working, i'll try it out and push that

<patched[m]>Bridge up again?

<mekeor[m]>patched: alright. maybe asking on help-guix mailing-list might be worth it

<mirai>is this name choice (serializer-kwargs) alright for this yet-to-be-proposed extension of define-configuration? <https://paste.centos.org/view/a86de436>

<patched[m]>mekeor @mekeor:matrix.org: I recall somebody sharing a hack to make gcc available in a shell, by passing an expression to guix shell -e

<patched[m]>The package gcc

<val[m]>patched: someone answered you, but you're not getting messages from IRC: https://logs.guix.gnu.org/guix/2023-06-03.log#214648

<mekeor[m]>oh, it's even more confusing because *some* messages do cross the bridge from libera to matrix. thanks, val!

<rekado>just noticed that the syntax highlights are unreadable in dark mode here: https://issues.guix.gnu.org/63852#2-lineno108

<patched[m]>val[m]: Ah, thanks val and jpoiret!

<vlorentz>test?

<vlorentz>mekeor[m]: oh indeed

<civodul>rekado: oh indeed

<jpoiret>civodul: so should we simply remove the syntax-case for match-record? I don't think that's the one thing causing problems here. Would you want to replace it with syntax-rules?=

<mekeor>emacs-ox-pandoc has (mistakenly?) been packaged as version 20180510. the latest version is "2.0". how to treat version decrease?

<civodul>jpoiret: it is syntax-rules currently on master, before this patch set

<civodul>i think it can stay that way

<civodul>and then, without the #,s bit, there's no risk of introducing a user-supplied ellipsis down the road

<civodul>(if this is what was happening)

<jpoiret>oh, you're right. Here i guess the objective *was* to get the whole form in the error message

<jpoiret>but yeah, might be too big, and we only want the location

<jpoiret>so let's just not apply that one patch

<jpoiret>i wonder why the error message doesn't have the proper location though

<ngz>sneek later tell rekado I kinda start to understand the hyphenation issue we're facing in modular TeX Live. It seems that texlive-babel must be among the TEXINPUTS when latex format is generated. IOW texlive-babel must an input for texlive-latex-base, which creates a circular dependency.

<sneek>Okay.

<civodul>jpoiret: for me it gets the right location, but that's the location of the whole match-record form; we'd prefer that of (fields ...) or similar

<jpoiret>with or without the patch civodul?

<jpoiret>i don't think giule can give us the location of the subforms unfortunately

<jpoiret>i'm very surprised by this but even the simplest syntax-rules macro with a syntax-violation on a bound piece of syntax can't report the location of it

<ngz>sneek later tell rekado circular dependency that is solved by building texlive-babel with pdftex engine. This does bode well…

<sneek>Will do.

<civodul>jpoiret: without the patch is fine; i do get the right location with the syntax-rules version i posted though

<civodul>we have tests for instance in tests/guix-system.sh that check for location in error reports

<janneke>(define-public glibc-locales

<janneke> (make-glibc-locales glibc))

<janneke>jpoiret: shouldn't these be (libc-for-target)?

<jpoiret>civodul: ???? now that abracadabra trick i really don't understand

<mirai>Any gexperts know how to read the built (mixed-text-file ...) from within the same source? I'd like to write a guix test that checks if the serializing procedure really writes the correct output <https://paste.centos.org/view/6093867e>

<jpoiret>how does adding some random piece of syntax that you don't use in the end add the location?

<mirai>I'd like to essentially automate ",use (guix) ,build (mixed-text-file ...)" ; "cat <the resulting path>"

<civodul>jpoiret: the piece of syntax we introduce inherits source location from the original form

<civodul>we don't actually care about what the content of that syntax object, we only care about its location

<jpoiret>mirai: have a look at https://yhetil.org/guix/87v8v2g9tm.fsf@jpoiret.xyz/

<jpoiret>civodul: yes, but even if we don't pass it to syntax-violation in the end it still gives the right location, which is what I don't understand

<jpoiret>i don't think we can get more precise than the match-record form location, but I guess that's fine, it's still logically close enough

<civodul>we pass it to syntax-violation: it's the 's*' there

<jpoiret>heh, no need to pass all of that, we can just re-use the s from the lambda of lookup-field

<jpoiret>we just need to rewrite it to not show the fom

<mirai>jpoiret: what's the "format helloes" for?

<jpoiret>mirai: ah, you can replace test-gexp by any file-like

<mirai>related, is it possible to sidestep "writing to a file"? That is, to get as a string what #~(....) will be "rendered" as

<jpoiret>or you can also have a look at (guix monad-repl)

<jpoiret>mirai: wdym by that?

<jpoiret>there's gexp->sexp

<mirai>in my paste <https://paste.centos.org/view/6093867e>, beginning at line 164, I'm only really interested in knowing if the variable 'Z' which is a Gexp is "equal" to the output from the "built" mixed-text-file

<mirai>gexp->sexp isn't recursive iirc

<mirai>I get nested gexps like this: <https://paste.centos.org/view/18d49959>

<jpoiret>mirai: isn't Z just a string?

<mirai>(eval (gexp->approximate-sexp ...) (current-module)) is out of question when it contains nested gexps

<lilyp>pretty sure you did something wrong when you have a gexp in (string-append ...)

<mirai>jpoiret: nope, Z is #~(string-append #~(format #f ....) #~(format ....))

<lilyp>yeah, those #~(format ...)s are superfluous

<jpoiret>mirai: i would expect gexp->sexp to work

<mirai>lilyp: nested gexps naturally occur in define-configuration

<lilyp>don't they get intermixed with #$ tho?

<mirai>(gexp->approximate-sexp ...) removes those

<mirai>otherwise it wouldn't even pass the ,build in the "original" paste

<mirai>(if the gexp wasn't intermixed with #$)

<lilyp>I'd really like an MWE here

<oriansj>?MWE?

<mirai>oriansj: same here

<lilyp>Like, a define-configuration with one boring type (e.g. an integer) field and a serializer

<mirai> <https://www.allacronyms.com/MWE> doesn't give me anything that would be relevant

<lilyp>minimum "working" example

<mirai>lilyp: <https://paste.centos.org/view/6093867e> , beginning at line 127

<mirai>or 115

<lilyp>we have different opinions on what's minimal then

<mirai>truly minimal would be beginning at 163, what would be the proper way to write a guix test that ensures that the serialization gives the expected output

<lilyp>that's not minimal, it depends on all the fluff that was before