IRC channel logs


back to list of logs

<dftxbs3e>zimoun, wait let me find a test case to try looks amazing
***lhp22 is now known as oswald_t
<zimoun>dftxbs3e: also give a look at etc/snippets/text-mode for Emacs and Magit.
<ngks>sheepish, a stray character made its way into the locale string. But I must say that I'm surprised the bogus locale string made it far enough to result in a backtrace like the one I pasted.
<oswald_t>hello there ! are my messages visible ?
<zimoun>dftxbs3e: note that it cannot be used blindy and manual check is still required. It is an helper not a full automation.
<ngks>oswalt_t: yes
<rekado>dftxbs3e: we have a yasnippet that uses staged data.
<rekado>the etc/committer.scm thing is nicer
<ngks>oswald_t: yes
<ngks>clearly I am a very poor typist
<oswald_t>If yes, i am playing with guix distribution, and I was wondering which packages are installed by default when a user is created ? Because, if I've well understood, each user has their own packages
<oswald_t>[thanks for your answers, sometimes I bug :) ]
<dftxbs3e>zimoun, omg amazing! thanks so much!
<lfam>oswald_t: No packages are installed by default for a user
<lfam>There are some packages provided by default, by the system, and the user can use those
<dftxbs3e>zimoun, etc/committer.scm
<oswald_t>But, for instance, bash is installed, isn't it ?
<lfam>Things like bash, coreutils, etc
<dftxbs3e>will add all this info to the awesome-guix list
<rekado>dftxbs3e: one caveat: etc/committer.scm only works with *updated* package definitions. It won’t do the right thing for package additions.
<rekado>haven’t gotten around to implementing it
<oswald_t>lfam : is there a file for configuring this ? or getting the whole list ?
<shcv>I'm trying to package a python library (ijson) that supports multiple versions of libyajl for the backend, and has tests for all of those
<lfam>oswald_t: It is defined here:
<rekado>for that I stage lines manually and use the “add” yasnippet
<bandali>civodul, rekado, hey, should the newer guix repos (and perhaps future repos as well) added since your request back in 2016 also get that update hook added to them for signature checking?
<oswald_t>lfam thanks a lot !
<shcv>however, I presume it's best to build it with just one of them?
<shcv>but then the tests fail
<lfam>oswald_t: So, that is the %base-packages you probably have in your config.scm
<bandali>also, if there are ever any desired improvements/changes for the hooks please feel free to ping me or bob and we'd be happy to install the changes
<shcv>any ideas what I should do to avoid running the tests for the other backends? Or should I add the other libyajl versions as deps?
<rekado>bandali: I would say “yes”, but IIRC there are also some repositories under the guix/ umbrella that may not need it (e.g. emacs-guix)
*rekado –> zzZZ
<shcv>er, I guess "inputs" is the appropriate vocab
<bandali>rekado, aha. since i don't wanna inconvenience anyone i won't do anything without confirmation from y'all, but i thought i'd point that out just in case :-)
<oswald_t>lfam yeah, probably :-) thanks, now I can study this :D
<zimoun>dftxbs3e: yw, but thanks rekado :-)
<dftxbs3e>zimoun, rekado: I just updated osip using those scripts! Basically what I did is: ./pre-inst-env guix refresh -u osip ; ./pre-inst-env guix build osip ; ./pre-inst-env guix refresh -l osip ; ./pre-inst-env guix build <all dependents> && etc/committer.scm && git push
<dftxbs3e>Would be nice make this all one command :-) - I'll make a shell script for that but Scheme would be better
<lfam>I'm wary of automating package updates too much :/ We should be sure to take some care
<lfam>For some packages, it doesn't matter or is impossible to do it "by hand". Like for Rust
<dftxbs3e>lfam, test suites and dependents building are good automated tests no? especially since osip is a GNU package
<lfam>Yes, those are good tests
<lfam>Like I said, the level of care depends on the package
<dftxbs3e>lfam, I think at some point we should even have GNU Guix Data Service do this for us and then gives us a patch as an URL to curl | git am -s in and double check then push
<rekado>for CRAN + bioconducter package updates I use ./etc/committer.scm a lot, but I also check the resulting commits. I wouldn’t dare push the results automatically. The code just isn’t smart enough to be relied upon.
*rekado —> really zzzZ
<zimoun>dftxbs3e, I agree with lfam and rekado
<dftxbs3e>zimoun, I agree too, but we could make it so actually validating the thing is one command or one button click away
<dftxbs3e>especially with system tests now..
<shcv>is there a scm function for replacing a specific line in a file? I'm not sure that using a regex with substitute* is wise
<lfam>I mean, it could be good to check the upsteram web page of the software, maybe the mailing lists and the bug tracker. Just to see if anything seems "off"
<benoitj>does anyone see ripgrep not building anymore?
<zimoun>dftxbs3e: well, if you want to practise your scheme, instead of writing a Bash, you should try to write a Guile script. Then using GUIX_EXTENSIONS_PATH, you can have your own and do: “guix update osip”
<lfam>There are different types of distros. One example is pypi, which is just a clearinghouse that redistributes code. Another example is Debian, where they are extremely careful about who can update what, and in what circumstances. It's expected that package maintainers read the upstream code and understand it. Guix can be in the middle.
<dftxbs3e>zimoun, I will try!
<lfam>There are no rules about how we handle it, but we should consider this spectrum of care and what we aim to do
<zimoun>lfam: to me, Guix behaves like Debian.
<lfam>Yes, but a little less strict
<lfam>Nobody owns packages here, for example. And we are able to roll-back if something breaks
<zimoun>hum? subjective. :-P
<lfam>However, we are not like Debian for Rust packages
<lfam>We import them, hundreds at a time
<lfam>Nobody is reading that code or checking for bugs
<lfam>Yes, it's subjective :) And we should automate things when it is appropriate.
<dftxbs3e>Minimizing repetitive work for me and making me focus on what I am capable of doing that a machine is not really increases my motivation to hack on and contribute to GNU Guix
<zimoun>lfam: I agree. :-)
<lfam>Yeah, that's an important point dtxbs3e
<lfam>I mean to spell your name right
<zimoun>dftxbs3e: yeah but from my point of view, it is different to have personal helpers (even shared as etc/committer.scm) and full automation
<dftxbs3e>zimoun, not full automation but helpers yes, helpers that do things and tells you what you should do as human
<dftxbs3e>so as a packager for example you just have to sit and follow a well-tested process, e.g. refresh + commit automated then prints a message: check the project home page for news before committing
<dftxbs3e>or mailing list or whatever
<lfam>That's a good workflow IMO
<dftxbs3e>also please publish your personal helpers x)
<zimoun>nckx: well, changing batch-size really increases the duration of “guix weather”. Hum! Not what I was expecting… Your bug report needs love. :-)
<vagrantc>lfam: you may have overly high esteem for Debian :)
<vagrantc>i mean, just look who packages guix for Debian ... you think they know how to read scheme? :)
<lfam>Well, I'm realistic about it :) But there is an ideal, too. As compared to a pypi-style distro
<lfam>No, nobody is reading all the Linux source code, not even Torvalds
<vagrantc>from what i hear, torvalds mostly just trusts the next pople down the chain and hardly even looks at code anymore
<lfam>Yeah, and those deputies only read their own parts, if that
<lfam>It's a hierarchy of reviews and vouching
<lfam>And Linux is super-buggy :)
<zimoun>dftxbs3e: here for example, I share my helpers when I hunt old forgotten bugs <>.
<shcv>where is substitute* defined?
<zimoun>shcv: (guix build utils) I guess.
<nckx>shcv: Without looking at the code, I'm almost certain that it's (guix build utils).
<nckx>Sorry if I missed any messages above; I won't read them now; I need to crunch and zzz. Good night Guix.
<dftxbs3e>zimoun, thanks.. also need to learn elisp..
<zimoun>dftxbs3e: do you use Emacs or something else?
<dftxbs3e>zimoun, I do use it
<dftxbs3e>zimoun, learned it solely for GNU Guix
<shcv>yep; I found it
<dftxbs3e>never used Emacs before
<xelxebar>Anyone here have vim-full installed? It's been failing for me for a while (~5 pulls within 2 weeks).
<zimoun>xelxebar: yes it is broken, see bug#46642.
<zimoun>dftxbs3e: about Emacs Lisp, this is a good pedestrian introduction. Well from my taste.
<dftxbs3e>zimoun, okay! thank you!
<zimoun>roptat: Hi! I am building camlboot and I am a bit confused because I am not able to parallelize the build (options -M or -c) and the Makefile seems a good candidate. So it takes ages. :-) Well, 4-6h had been reported, one on a laptop. What is your machine?
<davexunit>is it possible to add supplemental groups to the nginx user that the nginx service creates?
<davexunit>I need it to be a member of another group so it can have read access to files I want it to serve
<davexunit>alternatively: does anyone have a working cgit+gitolite setup? mine broke at some point because of file permissions.
<davexunit>I thought I had figured out a way to do it by making a new service type that inherits from nginx-service-type and changes the account service extension to use a modified set of accounts, but that just results in an error about there being 2 nginx services. presumably because the cgit service extends the official nginx-service-type
<davexunit>I thought I was being real clever, too :(
<davexunit>figured it out but boy is the solution ugly
<dftxbs3e>rekado_, impressive! it can also carefully detail full upgrade in commit message like what changed etc.
<shcv>is there a way to build a package up to a specific phase?
<shcv>because I tried to add a phase that modifies a file, but I'm not sure if it actually worked
<dftxbs3e>shcv, not AFAIK, but you can modify the package to make it intentionally fail and use --keep-failed then check failed build dir to see
<shcv>so somehow add a phase that fails?
<dftxbs3e>e.g. (invoke "false")
<dftxbs3e>just add this line after your operation
<dftxbs3e>and build with --keep-failed
<shcv>oh, so not in a new phase
<dftxbs3e>then inspect kept build dir in /tmp
<shcv>even easier than that; just return #f instead of #t at the end of my phase :)
<shcv>worked perfectly, and apparently my change was successful
<dftxbs3e>shcv, yes or this
<shcv>how do you delete a file?
<dftxbs3e>shcv, (delete-file "/path/to/file") - absolute or relative path
<shcv>ok, there's delete-file
<dftxbs3e>shcv, see GNU Guile reference manual
<dftxbs3e>some functions are implemented in GNU Guix itself, some others in GNU Guile
<dftxbs3e>so search both manuals always
<apteryx>the source snippet is not applied when using --with-git-url; bug?
<apteryx>there's this ugly error when running even just 'make clean' on v0.2.6.1: Unbound variable: #{\#t}#; would you have an idea where it might come from? It occurs after entering the doc directory
<apteryx>the backtrace has: (eval (for-each (lambda (m) (format #{\#t}# "../src/~a.scm " (string-join (# …) #))) (…)) #)
<apteryx>err, the two last messages were meant for #guile
<shcv>so it doesn't look like there are any service definitions for wireguard?
<apteryx>I thought mothacehe added some recently
<apteryx>are you using the latest guix?
<apteryx>try 'guix system search wireguard'
<Whyvn>I followed the manual for the postgres-service-type, but it seems to no be able to connect to the server when I try to do anything with postgres. I get the error "psql: error: could not connect to server: No such file or directory" I tried deleting the /var/lib/postgres/data directory and reconfiguring and restarting the service, but still same results.
<rekado_>dftxbs3e: committer.scm is a little primitive; it doesn’t yet attempt to summarize changes to the “arguments” field; someone looking for a fun project could add support to list the names of the changed/added/deleted build phases.
<dftxbs3e>rekado_, it's always impressive I think :-) - I tend to think the reason Scheme was used in GNU Guix is also to operate on code like this, read it easily, transform it easily, generate it easily
<dftxbs3e>already *
<dftxbs3e>I updated openssh, hope everything will be OK
<dftxbs3e>One server of mine upgraded and all things work still no problem
<rekado_>dftxbs3e: yeah, it’s a welcome property of S-expressions that makes it easier to write tools and extend Guix.
<sundbry>Whyvn: `psql` is probably looking for a unix socket to the server in /var/run/postgresql
<sundbry>try connecting explicitly with tcp
<Whyvn>sundbry: yeah when trying to create a user it askes "Is the server running locally and accepting connections on Unix domain socket "/tmp/.s.PGSQL.5432"? how can i explicityl tell it to use tcp
<sundbry>look at the psql manual
<sundbry>you can tell it to use that socket file /tmp/...
<sundbry>or tell ot to use host
<sundbry>i think its just -h
<Whyvn>ok thank you, i thought it was guix specific
<sundbry>im not sure why the guix build of postgres doesnt use the normal socket location
<Whyvn>werid it would be in guix manual, just following its examples
<sundbry> says the socket should be in /var/run/postgresql like normal
<aidalgol>Why is code for the step "Source etc/profile to augment PATH and other relevant environment variables" split into two command invocations, with the first setting an environment variable, instead of just doing it all at once?
<aidalgol>More importantly, for Build Environment Setup, should I set max jobs to the number of CPU cores I have, or can jobs run subprocesses in parallel?
<aidalgol>And is there any reason not to symlink the systemd unit files to /etc/systemd/system/ instead of copying them?
<nlyy>what's better, (for-each guix-download (map license-uri licenses)) or package with all licenses?
<kondor>Hello folks, just a question: i kust got a brand new ssd drive ~1Tb in size to dedicate to /gnu/store . Can I simply `dd` my existing /gnu/store onto that new drive, then mount it and all will be fine?
<nlyy>pls try, i wanna know too
<aidalgol>I'm getting this installing the 'hello' package: /gnu/store/pwcp239kjf7lnj5i4lkdzcfcxwcfyk72-bash-minimal-5.0.16/bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.utf8)
<aidalgol>My system locale is en_NZ.utf8.
<nlyy>install glibc-locales maybe?
<aidalgol>Ah, right.
<aidalgol>I have now installed glibc-utf8-locales and exported the GUIX_LOCPATH environment variable, and I'm still getting the hint about setting up locales.
<aidalgol>And still getting the "cannot change locale" warning.
<nlyy>good that it's just a warning
<nlyy>i have also seen something like that but just ignored it
<aidalgol>I want to use guix for a production application, so this is a little more concerning to me than if I were just using it for personal applications.
<aidalgol>Does running `sudo guix' run guix in the root profile, or does it have to be a root login shell?
<nlyy>sudo which <program-installed-with-guix> == which <program-installed-with-guix>
<nlyy>over here
<aidalgol>guix pull: error: got unexpected path `hint: Consider installing the `glibc-utf8-locales' or `glibc-locales' package and' from substituter
<aidalgol>OK, I resolved that by rolling back to a ZFS snapshot I took right after completing the base installation. I *royally* stuffed something up.
<sundbry>kondor: create a filesystem onthe drive and then cp the files normally
<sundbry>then modify your config.scm to use the new mount point, here is my config where I have a dedicated disk for /gnu
<sundbry>be prepared to screw your system up until you get it correct and have a strategy for rebooting whether with a live cd or booting the previous configuration'\
<sundbry>I recommend to use /gnu as the mount point and not /gnu/store
<sundbry>since /gnu/store gets re-mounted by guixbuild in its own containers
***rekado_ is now known as rekado
<aidalgol>I'm still getting the "locales" hint even after installing glibc-utf8-locales, exporting GUIX_LOCPATH, and even guix pull && guix package -u
<aidalgol>I'm not getting the "cannot change locale" warning, though.
<kondor>sundbury thanks, yeah you're right about gnu vs store
<kondor>sundbry ! sorry
<kondor>And yeah i'm prepared, hahah, ever since i realised how modifying services can shoot you into early boot guile :)
<abcdw>hi guix o/
<bonz060>hi abcdw o/
<civodul>cbaines: hey! looks like fc6d6aee66 is the culprit for the childhurd
<abcdw>Can someone merge please? It just makes an assert-valid-graph function public.
<cbaines>civodul, ah, right, maybe it's subtly changed whether a native or cross derivation is used?
<rekado>aidalgol: can you tell us what “guix describe” says?
<rekado>aidalgol: do you have the “guix” package installed (you should not).
<rekado>aidalgol: how did you start the guix-daemon?
<civodul>abcdw: i'll apply it later today if nobody beats me at it
<civodul>note that generally this kind of procedure is not a great interface
<civodul>that's why it's kept private
<civodul>but in this case it's prolly okay
<abcdw>civodul: thank you very much!) yup, got it.
***ae is now known as Guest97888
<avalenn>is it possible to be dropped in a Guile REPL at an uncatched exception with a guix command ?
<zimoun>avalenn: nothing I am aware.
<muradm>after guix pull, ripgrep fails to build
<mothacehe>looks like it's also failing on the CI:
<muradm>yes exactly same thing
<civodul>cbaines: childhurd issue is fixed now (commit 9fc4e94986e68e0e33b260e2389765e2d3b7dd07)
<cbaines>civodul, awesome :)
*civodul waits for the "fixed" notification email :-)
<rekado>avalenn: at least the load* procedure (which handles user code such as manifests) takes an “on-error” keyword argument to start a REPL.
<mothacehe>civodul: the test jobs are only evaluated periodically (every 24 hours), so you may wait a few hours :)
<rekado>avalenn: “guix system”, for example, accepts “--on-error=STRATEGY”, where one of the strategies is “debug”
<avalenn>thank you rekado. I will check that later
<civodul>we should extend that to the other commands
<roptat>zimoun, I checked your remarks on my patches for camlboot, but I can't find the indentation issues you're refering to
<roptat>I fixed the description, and changed the synopsis to "OCaml source bootstrap", because all the other "bootstrap *" are actually binary bootstrap packages
<roptat>I feel like when we use recursive? #t in a git-reference, we can't use software heritage because it influences the final hash, right?
<zimoun>roptat: about indentation, I think there is one extract spaces. I do not know.
<roptat>where exactly?
<zimoun>about SWH, I have never tried with recursive? #t.
<zimoun>for instance, in camlboot, (uri (git-reference then the next (url is one extra space, I guess.
<civodul>roptat: we could support recursive checkouts from SWH in (guix git-download), it's just more work
<civodul>basically we'd need to manually recurse into submodules
<zimoun>roptat: see here, the diff is attached.
<civodul>it's something swh-download could do
<roptat>so, only one space under for-each and git-reference?
<zimoun>I do not know, I have just set stuff in my Emacs config and then run M-C-q on the s-exp. But I could do wrong.
<roptat>looks like we have both
<Whyvn>is anyone successfully running postgres on guix system? I have the basic configuration for the manual. Leaving all the defaults how they are. In the pg_ctl log it says listening on IPv4 address, listening on Unix socket /var/run/postgresql/.s.PGSQL.5432 but when I sudo -u postgres -s /bin/sh and createuser --interactive it says it cannot find file or directory in /tmp/.s.PGSQL.5432, why would it use /tmp instead of /var/run
<Whyvn>for the socket?
<civodul>Whyvn: i'm using it for Cuirass with its default config, and apparently it works
<civodul>i know next to nothing about pg tho
<cage_>hi! i just submitted my patches to include a new package (and many libraries ;-)) to guix, i would like to thanks all the channel for the help!
<jackhill>Has anyone else experienced ungoogled-chromium-wayland occasionally crashing sway? It seems to happen mostly when creating a new chromium window. Unfortunately, I don't have much better information than that as I can't get it to happen consistently.
<jackhill>Or any advice on getting more information about it? I could open a bug, but I'm not even sure if it's a Guix problem, and that's all the information I have.
<zimoun>civodul: indeed recursive? #t for SWH will be cool! The SWH fallback needs some love. :-)
<roptat>zimoun, pushed :)
<roptat>now I'll let ci build camlboot and send other patches to include menhir built from ocaml 4.07
<roptat>hopefully, we can find a way to build 4
<roptat>4.09 from the current camlboot, but it's not guaranteed at all
<roptat>there might be new features not supported by the bootstrap
<zimoun>yeah, I think it is easier at first to use the new booted 4.07 to build 4.09
<roptat>it's not clear, because there might have been new features introduced in the compiler code, which require a bootstrap phase
<roptat>hopefully, there's no "hard bootstrap" anymore, but it means we'll have to build a few intermediate commits that might not be easy to find
<roptat>although we might consider that running a bootstrap in OCaml is ~6 minutes, compared to ~4 hours for camlboot
<simonsouth>10:51 *** NAMES @ChanServ @nckx [df] aadcg achow101 aidalgol Aleci[m] alextee alextee[m] alfplayer[m] Allan[m] AllanAdair[m]21 AlpineLlama amfl amk andi- andreas2 AppAraat[m] apteryx aquijoule__ ArneBab arpunk asabil atomsk298[m] avalenn avoidr aweinstock badpixel bandali bavier[m] bayfront-log_ bdju biotim BitPuffin boegel bojan_petrovic bonz060 bqv brandonmonkey87[ brettgilio_ brown121407 brown121407[m] bsima butl
<simonsouth>erian cage_ cairn cap cartwright case_ cbaines charmonium[m] cheers- chiefgoat chipb Christoph[m] civodul clemens3 clone11 colemickens CompanionCube cora_[m] curious_one[m] cyberwolf[m] cyrozap danielp3344 davexuni` davidl DavidWilson[m] daviid ddave[m] dddddd dec0d3r defaultxr Dennis[m] deselby dftxbs3e DiffieHellman dinglerod[m] DisLodge distopico divansantana dolfaqar[m] dongcarl donotshake[m] dragonscape576[m dr
<simonsouth>akonis dustyweb easilok[m] ece efraim eichin elais[m] elementsmatrix[m elibrokeit elliott_ emacsen emacsoma1 equalunique[m] erhandsome estraw euandreh Exagone313 faya01[m] Fd9a[m] FelipeBarros[m] FennecCode fitzsim fkz flomaysta[m] flor fnstudio Formbi fossguy[m]11 fr33domlover franz[m]1 fryguy ft g_bor[m] gambpang gate32[m] ggoes Gilly gn21[m] gnufr33dom GNUtoo goldenshimmer Gooberpatrol66 grumbel[m] grumble Hasnep
<simonsouth>[m] heloaoban hendi herlocks- hlz Hozanahin[m] Ikosit ilmu ioa iraklisk[m] iyzsong jackhill Jackneill janneke jb55 jbv1[m] jchmrt jeg jehelset JeremiahOrians[m jetomit jfred jgart[m] jgibbons[m] jjardon[m] jlicht jluttine jmarsden[m] joshaspinall[m] joshuagl jpoiret jsoo justinmoon jxyzn kaiwulf karpos[m] katco kensington kfvn khassanov Kimapr[m] Kimapr_ kini kisaja[m] kondor kozo[m] krastycraft[m] kristian1 langdon
<simonsouth> leomd leoprikler lewo lf94 librecat[m] Lightsword link2xt lispmacs lispmacs[work] lkd lmxyz[m] logiz luke-jr Lurkki[m] lycium[m] M7yd3r[m] madage maggotbrain MaJoe[m] malaclyps Mandraker[m] markasoftware marusich matijja matryoshka maxxcan[m] mbakke mekeor[m] mhj[m] michel_slm mid-kid MidAutumnHotaru midnight mjlbach mjw mood mothacehe mroh MrtnDk[m] muradm namtsui neuromorphic newline[m] NieDzejkob niko NinjaTrapp
<simonsouth>eur nlofaro Noclip Noisytoot nothingmuch null_radix[m] nullman numerobis OriansJ` ornxka overclucker PaulB[m] pavit23 pblom[m] penguwin pescobar pflanze phant0mas pie_ pinkieval pinoaffe pjotrp[m]1 pkill9 pmy pranavats pretzel profmakx PurpleSym pushcx questaetang[m] qyliss raghavgururajan regtur rekado Reza[m] rgherdt ricklepick[m] ride robmyers rojin[m] roptat roscoe_tw rotty Rovanion runejuhl ryanprior samueldr S
<simonsouth>anchayanMaity schaeffer scolobb` search_social semente[m] sesmca[m] ShadowJonathan simonsouth siraben sliced smartineng smithras sneek snybajl[m] spk121 srk ss2 stefanc_diff stikonas stikonas[m] str1ngs_ sturm sturm_ sumpfralle sundbry surpador terpri teythoon theruran thomassgn Tirifto[m] tricon undeadherbs[m] V valerii_leontiev ven[m] viaken vinzv[m] vlorentz vup w1gz wacatal[m] warren Whyvn wigust wingo wleslie W
<simonsouth>ojciech_K xelxebar xgqt xMopx xsabirx[m] yjftsjthsd zabe[m] zalox zbozbo[m] zimoun zjgkkn[m]
<ggoes>erc strikes again
<simonsouth>Oh God.
<Noisytoot>What was that?
<simonsouth>My bad, sorry everyone.
<simonsouth>Wrong keypress I'm afraid to say.
<lf94>emacs is sin
<pkill9>lol how did that happen?
<katco>lf94: you take that back!
<Noisytoot>Why is there an ERC command that does that?
<lf94>IIRC, ERC is an Emacs IRC client
<bandali>there is not, afaik
<ggoes>it might not be erc, but it's easy to accidentally post your whole log if you're using erc and yank something into the input field
<fitzsim>simonsouth: np :-) if it was ERC, what's the ERC keybinding so I can unbind it?
<ggoes>in my experience anyway
<simonsouth>This is rcirc.
<Kimapr_>there's an emacs irc command to send output of /names to a channel?
***Kimapr_ is now known as Kimapr
<fitzsim>ah, OK, not ERC
<simonsouth>I think I pressed C-m, which is mapped to rcirc-send-input apparently.
<fossguy[m]11><simonsouth "akonis dustyweb easilok ece efra"> What is this? :D
<bandali>C-m is just RET
<simonsouth>Oh right.
<lf94>lol, in emacs, it'd be like Meta-Ctrl-Shift-Space-N-S
<lf94>"whoops wrong keypress!"
<fitzsim>ERC protects against this, I think; it warns you for multiline pastes
<roptat>cage_, I think you sent your patches in a wrong way, it created one bug number for each, instead of only one for the series
<simonsouth>I'm honestly not sure what I pressed. Pretty sure I was aiming for M-v to scroll backwords.
<lf94>weechat warns you about multiline pastes too
<Noisytoot>What's the use of rcirc-send-input?
*nckx peeps in.
<simonsouth>Noisytoot: That's just what the Enter key normally does. I'm not sure what I pressed. :(
<siraben>simonsouth: C-h l
<bandali>Noisytoot, as the name suggests, it sends the input you've typed
<simonsouth>Well, anyway. Good morning, everyone.
<Noclip>Good morning
<simonsouth>siraben: Ah, that's helpful.
<jfred>lf94: IIRC for some pastes it doesn't, maybe middle-click pastes? (it's been a long time since I've used it, but I remember definitely accidentally pasting multiline stuff into a channel when I did)
<easilok[m]>Good morning and don't worry with that.
<roptat>cage_, it's not a big issue, but next time you should probably send a first message to open a bug number, then use --in-reply-to or in your git send-email command
<siraben>simonsouth: although if you've typed too much since then you'll lose the old lossage :P
<nckx>fossguy[m]11: An accident.
<Noisytoot>Good afternoon
<simonsouth>siraben: Yes, unfortunately that keypress is gone. But I'll know this for next time.
<lf94>jfred: they probably fixed that, because i've never had it happen once
<yjftsjthsd>You know, I used to literally run a keylogger on myself. At the time, I did it to get keyboard stats because I was interested in alternative layouts - it's easier to justify using a new layout if you can show that it's more efficient for the actual things you have actually typed - but you've just made me realize that it would sometimes help to
<yjftsjthsd>figure out what keybind I just accidentally triggered too:)
<simonsouth>Yep. I think I accidentally pressed C-m instead of C-v after scrolling back to the top of the log.
<simonsouth>IT seems rcric will "helpfully" resend the contents of whatever line your cursor happens to be on when you press Enter.
<Noisytoot>Is that a bug?
<cage_>roptat, sorry, this was my first time i sent patches using email :(
<cage_>thanks for your suggestion, i'll try to make a single-thread multiple-patches next time, sorry again
<Noisytoot>Could someone merge
<shcv>eww usually does pretty well, but those issue pages render horribly
<Noisytoot>There is an equivalent debbugs page
<shcv>it looks like your indentation changed on the python-crayons package
<Noisytoot>I used indent-code.el, so it should be correctly indented
<pretzel>Noisytoot: AIUI the `merge` command should work
<nckx>Noisytoot: Not all current code ‘obeys’ the indent-code.el rules; you should ignore its changes to unrelated packages (git commit -p).
<nckx>yjftsjthsd: <run a keylogger on myself> With a name like that, I can understand.
<shcv>ooh, the debbugs link automatically opens debbugs in emacs
<nckx>Your nick is basically me trying to type on {AZ,QW}ERTY.
<shcv>it would be fun to pick a name like qwfpluy
<nckx>Hullo sertified.
<sertified>I'm having trouble running a short bash script, that executes a binary
<sertified>It's really weird
<sertified>It's only 4 lines, can I paste it?
<bdju>how much do I have to do to switch to pipewire on guix?
<nckx>sertified: To please :)
<Noisytoot>pretzel: I meant merge it into Guix, not merge it with another bug report
<balance>Hello! Please help with next question (already asked but can't find info how to do that).
<balance>How to do detached header with luks (no lvm) on guixsd? When i do "guix system init /mnt/etc/config.scm /mnt" a error occurs "/mnt/etc/config.scm:22:22: error: no LUKS partition with UUID '11111111-aaaa-2222-bbbb-333333333333'" (here using fake UUID). Read manuals but did not find an example with detached header.
<balance>Read about `info guix "Initial RAM Disk"` but cant find how to put header and key (for the purpose not to enter luks password twice) to initrd? and how to write correct /etc/config.scm for the case described above?
<nckx>There is no built-in support for that, so why it's certainly possible (‘everything's possible’ with a Turing-complete configuration system) you'll actually have to create the Guix LUKS Detached Header System.
<sertified>nckx: If I run this script explicitly with bash, it says that ./vscodium/codium does not exist
<nckx>It won't be as simple as adding a file to the initrd (there's no code that will do anything with it) but you can customise the code that invokes cryptsetup.
<nckx>sertified: That's because the error message is misleading.
<nckx>Don't you get the same error when you invoke it manually?
<sertified>nckx: I get the same error when run ./codium
<sertified>I've tried $ source codium but it says it cannot run binary file
<nckx>Binaries compiled for other distributions hard-code (by necessity) the location of the linker-loader, usually ‘/lib/’. This does not exist on Guix. Unix being unix turns this into a useless error message; but it should really be ‘/lib/ no such file or directory’.
<nckx>You can use patchelf to edit the binary itself to change this hard-coded location, or create a symlink.
<Noisytoot>Does ./vscodium/codium actually exist?
<sertified>Noisytoot: Yes
<sertified>nckx: I will make the symlink
<nckx>sertified: You can't source a binary.
<nckx>sertified: Are you on Guix System?
<sertified>nckx: Yes
<nckx>Well, that's only one step of (probably) many, since you'll have to point it to all needed libraries as well.
<Noisytoot>Is VSCodium in Guix?
<balance>nckx: Thank you for answer! How to customise the code that invokes cryptsetup, or where to read about that?
<sertified>Noisytoot: No. And I need to run this particular VSCodium since my professor pre-installed a Lean prover extension, which only exists for VSCode. Not to mention the Lean library that is specific for this class.
<nckx>sertified: You can add something like to your system.scm to create the link for you, so it will always point to the current glibc.
<Noisytoot>sertified: Can't you load the extension into another VSCodium?
<nckx>Once you get that right, the error message will change, and you can use ‘ldd codium’ to see which libraries it needs.
<nckx>ldd is provided by gcc-toolchain, and probably some other packages too.
<xgqt>simonsouth: lol
<Noisytoot>Can be merged as it is, or do I need to remove the python-crayons indentation changes?
<nckx>balance: I'd start here: . Well, actually, start by running Guix from a local git checkout so you can edit it, add detached header support, and submit it as a patch upstream 😉 (‘Building from Git’ in the manual).
<nckx>Noisytoot: It's better if you send an updated patch without the changes.
<Noisytoot>nckx: Should I send it as a reply or as a new patch?
<nckx>Noisytoot: And put the strings following base32, home-page, and synopsis on the same line as the ‘(’:
<nckx>As a reply.
<balance>nckx: :-D
<nckx>Noisytoot: Descriptions consist of full sentences, so start with ‘Mistletoe is...’.
<nckx>There, you suckered me into reviewing ^_^
*nckx AFK now.
<Noisytoot>mistletoe's readme says "Remember to spell mistletoe in lowercase!"
<balance>nckx: Thank you for link!
<bavier[m]>Noisytoot: can you use some of their own wording to avoid putting the name at the beginning of a sentence?
<Noisytoot>bavier[m]: Descriptions should be full sentences
<Noisytoot>Currently it's "A CommonMark-compliant Markdown parser
<Noisytoot>that supports easy definitions of custom tokens.
<Noisytoot>Parsing Markdown into an abstract syntax tree also allows mistletoe
<Noisytoot>to swap out renderers for different output formats,
<Noisytoot>without touching any of the core components."
<pkill9>can the nginx service be updated so that individual blocks can be pre-written configs, currently there is a 'file' field that will overwrite all the config
<pkill9>well my question is is this possible currently
<pkill9>though what i want doesn't need this actually i think
<bavier[m]>Noisytoot: right, I was just hoping there might be some full sentences is upstreams docs that would also satisfy `guix lint`s desire to have sentences begin with a capital letter.
<Noisytoot>"Apart from being the fastest CommonMark-compliant Markdown parser implementation in pure Python, mistletoe also supports easy definitions of custom tokens. Parsing Markdown into an abstract syntax tree also allows us to swap out renderers for different output formats, without touching any of the core components."
<Noisytoot>^ from the README
<Noisytoot>But "fastest" is subjective
<Noisytoot>Something else could be faster on a different computer
<Noisytoot>"Please avoid marketing phrases such as “world-leading”, “industrial-strength”, and “next-generation”, and avoid superlatives like “the most advanced”—they are not helpful to users looking for a package and may even sound suspicious. Instead, try to be factual, mentioning use cases and features. "
<bavier[m]>how about: "The @code{mistletoe} Markdown parser is CommonMark compliant and also supports easy definitions of custom tokens." done.
<bavier[m]>or leave out the "easy": "The @code{mistletoe} Markdown parser is CommonMark compliant and supports definition of custom tokens."
<nckx>Noisytoot, bavier[m]: We can respect upstream's wishes but shouldn't bend over backwards (or the rules or readable English) to do so. Like Wikipedia.
<nckx>E.g., I'm sure we call ‘openBLURF’ OpenBLURF somewhere.
<nckx>But I like bavier[m]'s suggestion.
<bavier[m]>nckx: I agree. In this case it seems easy enough to satisfy. :)
<nckx>It's even better at stuffing an extra search keyword in there ☺
<nckx>Oh, Markdown was already in the original, never mind.
<pkill9>it would be good if guix's certbot service also added a herd service, so instead of going into mcron to get the path to the script and then run it, you can run `sudo herd start certbot`
<nly>how to revert a guix pull?
<sneek>nly, you have 1 message!
<sneek>nly, mwette says: with fix to nyacc ffi-helper I was able to generate a guile wrap for libfuse. If you want to try I would need to send it to you as oto big (at 200 kB) to paste. I'm guessing it would need some front-end work to make useful.
<nly>i'll be more than happy to test it mwette
<bavier[m]>nly: `guix pull --help` shows `guix pull --roll-back`
<nckx>nly: --roll-back.
<nly>i pulled 2ice
<nckx>And rolling back twice rolls back the rollback?
<nly>thank you
<nckx>guix pull --commit=<commit>, then, I guess, although I consider the behaviour you (appear to?) describe problematic.
<nckx>Oh, you didn't roll back?
<nly>it worked
<nly>sneek later tell mwette ill be more than happy to test guile libfuse
<sneek>Will do.
<dongcarl>Does anyone know how hard it'd be to have `guix environment` accept derivations as the argument in addition to packages?
<dongcarl>I've run into this several times now, where I have derivations which are not searchable fail, and I'm unable to use `cd /tmp/blah-0 && guix environment <...blah.drv>` to start debugging the build
<pkill9>does anyone know how to use `build-package` from guix/scripts.scm?
<midnight>simonsouth: :-D
<zimoun>dongcarl: why not ‘cd /tmp/blah-0 && guix environment blah‘?
<dongcarl>zimoun: Because blah is not available as a named package
<dongcarl>It's a custom package in a manifest
<zimoun>does the package have a symbol in the manifest?
<zimoun>dongcarl: it does not answer your question, but something like ’guix environment -L foo -e '(@@ (a module name) blah)'’; assuming you add a module definition in your manifest and the custom package is defined by a symbol.
<zimoun>and I agree that maybe passing a derivation to “guix environment” could be useful for debugging. :-)
<dongcarl>zimoun: Oh yeah for sure I can hack around it... It's just so nice to be able to copy paste the derivation path and do `guix environment`, just like how `guix build` can handle it, you know?
<dongcarl>Does anyone know the difference between x86_64-linux-gnu and x86_64-pc-linux-gnu?
<zimoun>dongcarl: maybe
<dongcarl>Yeah... But like... I don't know a vendor named "pc", so why not "unknown"? Why do distros insist on "pc"??
<zimoun>hehe Each time, mothacehe or civodul or janneke explains me why and I never remember :-)
<zimoun>dongcarl: about derivation and environment, well I guess no one had been enough annoyed at debugging to implement it. :-)
<leoprikler>i think it's historical, though some might say hysterical :)
<paulj>Evening all! I am working through the packaging example using the GNU hello package, but I have come across an unexpected error. According to the result of "guix download mirror://gnu/hello/hello-2.10.tar.gz", I have "No space left on device". In this paste - - you can see I have run guix gc, then show the disk free as >70% of disk space, and the error message from guix download. Have I missed
<roptat>paulj, what does df -i tell you?
<paulj>58% IUse%
<rekado>y’all should take a look at this:
<rekado>this is most excellent!
<jeko>Hello Guixters !
<roptat>rekado, I pushed camlboot earlier today, our ocaml-4.07 it now bootstrapped :)
<andreas-e>roptat: Congratulations, that is some amazing work!
<roptat>paulj, I wonder what is wrong then, it looks like you do have more space on the device...
<jeko>roptat: Congratulations !
<nckx>paulj: Do you use ext*fs?
<nckx>Does ‘sudo tune2fs -l /dev/foo’ contain dir_index?
<paulj>It's a very vanilla setup on a Lenovo laptop, to enable me to get into guix more.
<paulj>...let me try that...
<pkill9>who needs a file upload service when you have nginx and scp
<nckx>pkill9: Word.
<civodul>roptat: woow, thumbs up!
<paulj>nckx: Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery extent 64bit flex_bg sparse_super large_file huge_file dir_nlink extra_isize metadata_csum
<paulj>...yes to dir_index
<nckx>OK, that's the culprit (it's common: ext4 has a design flaw in that it hashes directory entries and... just dies when the hash table gets ‘full’). Try ‘tune2fs -E "hash_alg=tea" /dev/foo’ to select a different hash algo, or ‘tune2fs -O "^dir_index" /dev/foo’ to disable it completely if that doesn't help.
<nckx>I think that works on on-line file systems...
<civodul>roptat: i wonder if we could turn the miniml compiler into a proper Guile compiler front-end, while we're at it :-)
<paulj>nckx: Seems to have worked - no error message
<nckx>The tea one?
<paulj>...and the download command now works correctly. Thank you! Should I modify my system config.scm to set this for the future?
<nckx>No, it sticks.
<paulj>Good - thanks.
<roptat>civodul, you mean compiling ocaml to guile bytecode then?
<roptat>I don't think it would help the bootstrap, but could be fun
<civodul>Guile has this "compiler tower" that makes it easy to add a language front-end
<nckx>The trade-off is that scanning directories is now (theoretically at least) slower. Not much we can do, short of reorganising /gnu/store to use, e.g., /gnu/store/aa/aaaa...-style hacks to work around one broken file system.
<civodul>roptat: yeah, fun is what i had in mind :-)
<nckx>(= not going to happen)
<paulj>Should I have used a different file system other than ext4? If so, which would have been the preferred option?
<civodul>roptat: anyway congrats to the whole team! it's great that Gabriel & co. got into this
<nckx>paulj: I don't really know. People seem to be successfully using btrfs. We should probably add a hint about ext4 to the manual... this has happened several times by now.
<paulj>I am on the manual page at the moment, and it shows using ext4 when setting up the partitions,
<nckx>paulj: You definitely didn't do anything wrong; it's rare enough that I'm sure plenty of people run Guix on ext4 without a care. Maybe it depends on the exact contents of your store. Maybe there has to be a collision. I don't use ext4 myself.
<nckx>Yes, we recommend the file system that sometimes breaks.
<nckx>People were discussing changing that to btrfs about a year ago, guess it never happened or not completely.
<paulj>I'll stick with this at the moment, and consider changing to btrfs at some point in the future. I don't know anything about btrfs yet (like, is it stable!).
<paulj>Should be easy to start again on this system - I have worked hard to make sure everything is installed through manifests, so redoing it should be straight forward.
<paulj>Looking at the wiki page, seems like Brtfs is well used and no issue :). Maybe I will test out my ability to hose the system and re-install again...
<nckx>I've opened a bug report to remind myself to add a note about ext4.
<paulj>Thanks. I didn't answer your question between my posts above - yes, changing the hash algo to tea worked.
<nckx>Ah good, that probably avoids a performance hit completely.
<paulj>In that case, I will continue on my journey to create a package for ts, and look to play with file systems later.
<nckx>(What's ts?)
<paulj>taskspooler. It's available here:
<paulj>It comes packages for debian systems already, but doesn't seem to be on guix yet. I thought it would be a good way to get into packaging, as it isn't too complicated/
<scm>Heh, every time someone says something about a .scm I get notified that someone has spoken to me. :)
<nckx>Interesting. I actually looked at the Debian index first, but didn't find a ts package.
<nckx>scm: You knew what you were signing up for 😉
<paulj>On debian, I think it is called tsp to avoid a name clash
<nckx>...'s Like calling yourself ‘regression’ and lurking in ##linux...
<nckx>paulj: Ah.
<nckx>‘Your keyword was too generic.’
<scm>nckx, ha. Yes, indeed. :)
<paulj>I have to go - thanks nckx - see everyone soon...
<rekado>Madalin and I revived one of the build nodes (hydra-guix-128) today. Networking was never correctly set up and the serial console baud rate was also misconfigured, so we always postponed fixing it.
<rekado>I’m now reconfiguring it with “guix deploy”
<rekado>is there something else I should do to connect it to cuirass?
<civodul>rekado: nice! if you use the same config as the other build nodes, it should have the cuirass stuff too
<civodul>"remote worker", i think
<rekado>okay, cool
<rekado>I’ll just reboot it once it’s ready
***amfl_ is now known as amfl
<zimoun`>is someone using “guix graph -b d3js”? If yes, how? Maybe rekado? Or why the default is chord? Hard coded in guix/d3.v3.js right?
<rekado>yes, it’s a chord graph
<rekado>I found it useful to see at a glance how the packages are related
<zimoun`>ok, because i find what civodul did for services nice for exploring the graph. Even if I do not know if it scales well for packages.
<civodul>zimoun`: performance-wise, d3 scales rather well, but in terms of visualization, i think it wouldn't be very helpful
<vagrantc>not sure exactly what's missing, but i'm unable to authenticate 3aacc9f1dae2f68d623dae540fa050f1a87d2519
<vagrantc>on master
<civodul>unless d3 provides things for clustering
<rekado>yeah, I decided on the chord graph because it doesn’t turn into a hairball
<rekado>with plain networks you often end up with something that’s just a big mess
<civodul>vagrantc: could it be that your "keyring" branch isn't up-to-date?
<dftxbs3e>vagrantc, I checked, commit's properly signed
<vagrantc>civodul: one one of the branches appears out of date ...
<dftxbs3e>Snice it's my commit, I have make authenticate set up
<vagrantc>admittedly it is a bit hard to track...
<dftxbs3e>vagrantc, git fetch --all --tags ?
<dftxbs3e>civodul, is that expected it warns about a recent commit rather than all older ones I made?
<vagrantc>running from a guix checkout, the keyring branch *was* up to date ... but one of the ones in .cache/guix/checkouts was not
<vagrantc>will see if that fixes it...
<vagrantc>but notably, one of the other ones in .cache were up to date as well ...
<vagrantc>run into this periodically and it's a bit confusing exactly what branches need to be updated when and where...
<zimoun`>yeah, currently dot is unusable in practise. And I am annoyed by my iterations with “grepping” in the dot. And, I am in the mood about graph: I would like to be able to visualize what happens when an input is added/removed. Or what is the graph for pkg1 and pkg2 compared to pkg1 alone. etc.
<vagrantc>dftxbs3e: what i find confusing is it clearly successfully authenticated commits by you in the past
<vagrantc>same key, from what i can see...
<shcv>has there been any work toward a decentralized build/substitute system? it seems like it should be pretty doable, especially if you require ID registration to prevent sybils
<dftxbs3e>shcv, decentralized build, cuirass is decentralized but not a public system, distributed substitute system yes ipfs and gnunet is pending for that, and no trust required there.
<dftxbs3e>ipfs/gnunet substitutes would need to be reproducible, so they can still be verified against official GNU Guix signing key
<shcv>obviously once the hash has been identified and verified, it substitutes can be distributed easily
<shcv>but I think it should be possible to use a slightly more decentralized approach for the initial verification step
<dftxbs3e>shcv, I don't think public decentralized build in a distributed network is a problem GNU Guix will solve
<shcv>e.g. a quorum of keys registered with the repo just like the current .guix-authorizations (maybe the same keys)
<dftxbs3e>shcv, signing key distribution is just classical person-to-person web-of-trust
<shcv>I think it could be (and probably would need to be) slightly more than a web of trust
<rekado>zimoun: one thing I always wanted to do is to let d3 only render the first level of dependencies and only reveal the next level on click.
<rekado>the problem here is that duplicates will not necessarily be linked to existing nodes unless you arrange for that to happen
<vagrantc>well, that commit authenticates now ...
<zimoun`>rekado: yeah, I agree. It could be nice to have. Currently it is purely static since civodul explorer uses web server (if I remember correctly).
<vagrantc>hah. only had to re-sign the diffoscope commit twice!
<vagrantc>can substitute match multiple lines?
<vagrantc>would be nice to get rid of the skip-dex-test-with-missing-procyon phase in diffoscope and get that fixed upstream ... but i think the current substitute call might match multiple tests ... need to test which tests are affected for sure before pushing upstream
<rekado>zimoun: you could load the whole graph into d3 as JSON and then do without a server.
<dftxbs3e>projects that release security patches without making a release are really annoying
<vagrantc>or package procyon for guix ... but last i tried that some firm tugging of hair was involved
<rekado>“guix deploy” for the revived build node failed
<lfam>Agreed dftxbs3e
<rekado>Throw to key `match-error' with args `("match" "no matching pattern" ("none" "/sys/kernel/debug" "debugfs" () #f #f #f))'.
<lfam>I think that, traditionally, this was considered good practice. Distros like Debian won't update the package anyways, but only patch old versions, so upstreams learned that it wasn't important to release for security updates
<rekado>I tried mounting the debugfs manually, but I still can’t get the service to start
<dftxbs3e>lfam, qemu's handling of it and grub2 recently is extremely annoying
<rekado>is there a way to tell “guix deploy” not to bother restarting services?
<rekado>I’ll reboot the node anyway
<dftxbs3e>lfam, do we set a goal to ourselves to gradually reduce the size of this list to only false positives?
<dftxbs3e>would be nice if we could annotate individual problems and say why they are false positives so they don't appear in the list
<lfam>If it is useful, sure. I'm not familiar with that site
<dftxbs3e>lfam, it's actually a really great site! I have NVD rss feeds as well and many others but that repology Free Software site does really lots of work we could use, a bit like what GNU Guix Data Service could do in the future
<lfam>Taking the first package as an example, 389-ds-base
<lfam>Is there somewhere to click that explains what is wrong
<lfam>I assume red is "bad" and green is "good"
<dftxbs3e>lfam, red means outdated, warning sign means maybe vulnerable
<lfam>Looks like every distro has an outdated package except for Fedora Rawhide
<dftxbs3e>lfam, Fedora probably has the strongest and largest (employed) workforce
<rekado>that’s how they computed “outdated” — if there’s any other distro with a newer version all others are “outdated”
<lfam>I guess it omits RHEL
<rekado>I like to ignore repology and use “guix lint” instead.
<dftxbs3e>rekado, repology looks at upstreams AFAIK
<rekado>(can they mark the whole distro as outdated? That’s what RHEL is.)
<nckx>dftxbs3e: Really? How?
<lfam>They must have an army of web scrapers
<nckx>I thought they did what rekado says.
<lfam>They are probably experts at scraping at this point
<nckx>I don't think so.
<nckx>That does not sound like Repology :)
<lfam>Alright, I was just guessing based on the diversity of projects they have data on
<nckx>lfam: They just pull all repositories, compare the versions, and see who has the highest.
<rekado>they repeatedly pushed us to host a file that they can ingest
<nckx>You give them way too much credit.
<lfam>Adding the cpe-name property to more packages will let us improve CVE coverage of `guix lint`
<dftxbs3e>lfam, yes I am looking forward to this
<vagrantc>maybe i need to actually patch diffoscope...
<lfam>We definitely aim to keep our packages up to date and not diverge too much from what upstreams release
<dftxbs3e>lfam, I would very much like a branch where I can break stuff without fear as in, always update to latest version everything without fear of mass rebuilds
<dftxbs3e>then GNU Guix master would be downstream of that
<rekado>that’s what core-updates is
<shcv>anyone else having problems building ripgrep-12.1.1?
<dftxbs3e>well.. we push stuff to master directly most times? rekado
<lfam>shcv: If there is no substitute for it, then I'd say that everyone will have problems building it
<nckx>dftxbs3e: Only if it doesn't cause mass rebuilds, so you needn't fear them.
<lfam>The guidelines for which branch to use are here:
<lfam>The thing to remember is that using the newest version of every program will not create a working operating system. We have to do a lot of work (largely automated with the system tests) to validate things, and that is what "distros are for", which is sometimes forgotten by the anti-distro single-language people
<lfam>Usually, we do something like you describe for several months. We just update everything we can think of on the core-updates branch. It's totally broken. Then we fix it, which takes another few months. And only then is it useful
<dftxbs3e>I understand, what I meant is that master isnt really a downstream to core-updates
<lfam>That's true