IRC channel logs


back to list of 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
<|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|>Anyway, you all can dislike me now
<|F9|>cause I use OS X
<|F9|>non-free os
<Fare>Nix runs on OS X... though as of late, the installation isn't seamless anymore.
<|F9|>Thanks for link, I may try
<|F9|>A bit offtopic, but overall, how bad is OS X?
<Fare>I think the one that was missing from my config might have been
<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|>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|>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|>Also, about software, it mostly shit everywhere.
<|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|>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> # 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?
<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
<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 and
<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
<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: <>), in a magit-status buffer, type "W c s". this is my config:
<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
<jpoiret>i'm thinking that we should drop "records: match-record: Display more helpful field-not-found error."
<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 right?
<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
<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)
<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>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? <>
<patched[m]>mekeor 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:
<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:
<patched[m]>val[m]: Ah, thanks val and jpoiret!
<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.
<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/ 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 <>
<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
<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 <>, 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: <>
<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
<mirai>oriansj: same here
<lilyp>Like, a define-configuration with one boring type (e.g. an integer) field and a serializer
<mirai> <> doesn't give me anything that would be relevant
<lilyp>minimum "working" example
<mirai>lilyp: <> , 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