IRC channel logs

<radio->For some reason I'm currently unable to pull from my channel

<nckx>Other flavours are available. Try them.

<radio->When building the channel derivation I get:

<radio->building /gnu/store/f4l27lh2rrk9kj6kayvvjxajllljxvn2-radix.drv...

<radio->|builder for `/gnu/store/f4l27lh2rrk9kj6kayvvjxajllljxvn2-radix.drv' failed to produce output path `/gnu/store/znmxghcpkph2aigarz7sndyh1cy6na1g-radix'

<radio->build of /gnu/store/f4l27lh2rrk9kj6kayvvjxajllljxvn2-radix.drv failed

<radio->View build log at '/var/log/guix/drvs/f4/l27lh2rrk9kj6kayvvjxajllljxvn2-radix.drv.gz'.

<radio->cannot build derivation `/gnu/store/9h3i8izdqnp0xd9jpxyhqv0gl7214fz6-profile.drv': 1 dependencies couldn't be built

<nckx>Whilst you're quieted by a bot for flooding: we'll need to see the contents of the .drv.gz log.

<nckx>And you'll want to put them on a pastebin, like the paste.debian.net in the topic.

<nckx>(You can talk again now.)

<radio->Here

<radio-> http://0.vern.cc/sC.txt

<nckx>Uh.

<nckx>That looks like a networking error, but whence.

<nckx>That -8 better not be an errno.

<nckx>radio-: Is this reproducible?

<radio->Yeah, usually getaddrinfo errors are related to networking problems, but I couldn't find any source of the problem inspecting my network related stuff

<radio->nckx: wym?

<nckx>Does it reliably happen each time you run the command?

<radio->Yes

<radio->Both on doas guix pull and on guix pull (root and radio share use the same channels)

<radio->Also I tried to remove my channel from the channel list, and then it pull correctly, but putting it back, I get the same error again

<radio->Also changing the channel introduction doesn't make a change

<radio->I tried to pull after establishing different wireguard connections, and I get the same problem

<nckx>Could you share your channel? If I didn't know any better (and I don't) I'd say it's trying to network inside the build environment whilst pulling...

<radio-> https://codeberg.org/anemofilia/radix

<radio->Here

<nckx>Thanks.

<nckx>(Then again, -8 is exec format error, so who even knows.)

<radio->:/

<nckx>I was hoping for a smol channel with a single file with an obvious error, but no, you had to be all impressive and make this. It's still pulling :)

<radio->oiufdshsdoiudsfhoiudsf thanks

<radio->:)

<radio->Actually, it used to pull way faster than it's at the moment

<radio->And IDK why

<radio->I didn't make any big commit to it recently

<radio->Hmmmmmm this is pretty strange...

<radio->I managed to pull it now

<radio->After removing the last commit with rebase

<radio->The strange part is that the last commit was really simple

<nckx>Yes.

<radio-> http://0.vern.cc/s8.scm

<radio->Here

<nckx>(I was also doing a rudimentary ‘bisection’ here. Guix pull is slooow.)

<radio->The commit I removed only inserted this file

<nckx>Ah.

<radio->And changed the kakoune ocurrence in buer.scm to kakoune-next

<nckx>Right, that won't work.

<nckx>‘with-latest’ reaches out to the Internet. You can't do that in the build environment.

<radio->Hmmmmm

<nckx>You'll have to delay that until evaluation time.

<nckx>And sorry for the abrupt good-bye, but I have to run.

<radio->That's really good to know

<nckx>o/

<radio->NP, thanks for the help

<radio->Is there any reason that options->transformation treats an assoc-list differently depending on the order of the associations passed to it?

<radio->I discovered just now that (options->transformation

<radio-> `((with-branch . "kakoune=master")

<radio-> (with-git-url . "kakoune=https://github.com/mawww/kakoune")))

<radio->Works just fine

<radio->But if you specify the git-url first it simply doesn't work

<radio->Which not only is counterintuitive and undesirable IMO, but also strange. If I would force some ordering, I would prefer to get the git-url before the branch

<radio->I must be doing something wrong

<radio->I ain't

<radio->It does seem to comute in the shell http://0.vern.cc/sN.txt

<yewscion>Hey Guix, quick question: What's the canonical method for specifying a specifc package output or version inside of a package definition these days? I never memorized the required syntax after the big change...

<cnx>for output it's #$(this-package-*input), not sure about version

<iyzsong>should be: (list foo (list bar "bin"))

<yewscion>cnx: iyzsong: Thanks! iyzsong, I think that was what I was looking for. Appreciate the help as always!

<iyzsong>cool :)

<cnx>ah thanks iyzsong for the correction

<yewscion>Follow up: Is there a way to specify version, but not output? I am trying to reference gtk+ for gtk2, but the code selects output aftr the specification of the package...

<yewscion>Nevermind, was able to just explicitly specify gtk+-2 as the package instead, in this instance.

<yewscion>Sorry for the noise!

<cnx>ACTION is once again asking for reviews for the patchset adding senpai irc client: https://issues.guix.gnu.org/64222

<mirai>cnx: have you considered fixing the documentation install step upstream?

<cnx>i haven't, i'll see what i can do

<cnx>wait mirai, it's not broken

<cnx>the reason the guix package installs it manually it's because go-build-system is used and it does not run make install (?)

<ackd>GUIIIIIIIIIIIIX

<ackd>A long while ago, I installed vkdt using someone else's package file. Is there a way to check how I did that?

<ackd>(I want to update it)

<ackd>Ah, I think I found the scm.

<ackd>Thanks for packaging this, podiki

<podiki>ackd: oh welcome! I have a newer version locally I think, should get it in guix finally

<ackd>I was going to try to hack it together to thumb through some meteor exposures, but it can probably wait.

<ackd>What's your process for getting it in there?

<podiki>Clean it up/check all looks good (license, etc) and submit patch

<podiki>(there's details in the manual if you never did such a thing, for future reference)

<ackd>Aye, I need to read the FUNKY manual. It's still after I finish HTDP, sadly

<ackd>I should have planned that better, as I completely overestimated the difficulty of learning scheme, to pleasant surprise

<nckx>lilyp: <emacs> Yay.

<lilyp>yeah, sorry, was in Japan last week

<nckx>Jelly.

<junkyard>is it possible to switch the default greeter to lightdm?

<civodul>junkyard: hi! yes, you can do that by changing your service list, as hinted in https://guix.gnu.org/manual/en/html_node/Using-the-Configuration-System.html#System-Services

<civodul>specifically, you need to do (modify-services you-services (delete lightdm-service-type))

<civodul>and on top of that, (append (list (service lightdm-service-type)) ...)

<civodul>er, it's gdm-service-type that you want to remove

<thanosapollon>Are you planning for any new presentations/talks about guix?

<junkyard>civodul: sadly it's not working, it's basically saying lightdm-service-type is an unbound variable

<junkyard>despite me importing the xorg service module

<bjc>junkyard: use ‘guix system search lightdm’ to find the module a system service is in

<bjc>in this case it's (gnu services lightdm)

<junkyard>it's telling me remove is an unbound variable

<junkyard>there is something wrong here

<nckx>junkyard: It's not a variable. Did you import (gnu services)?

<nckx>Oh, the things you just need to know™.

<junkyard>nckx: yeah am pretty new to this- guess it's gonna be a bumpy road until i have a decent configuration going

<junkyard>even importing gnu services remove shows unbound huh

<nckx>Can you share your configuration file?

<nckx>This is probably a side-effect of something else.

<junkyard>this is a brand new install on a vm, i struggly to think of anything that may be affecting it

<nckx>New syntax errors? :)

<nckx>The error message might be misleading. Guile likes those. A lot.

<junkyard> https://pastebin.com/FBxeYxcJ

<nckx>Oh.

<nckx>So.

<nckx>(Sorry, I was out.)

<civodul>junkyard: for 'remove', you need to (use-modules (srfi srfi-1))

<civodul>we should really improve the manual here

<nckx>I'd use modify-services.

<parnikkapore>yeah, looks like it was in a modify-services but is removed from it

<nckx>Nah, it's a valid SRFI remove, but copied from somewhere(?) without the right module.

<nckx>The modify-services remove is simpler.

<parnikkapore>oops yeah, on second reading, it's probably srfi-1 remove

<nckx>(modify-services %desktop-services (delete gdm-service-type)) ; done.

<junkyard>alright, that's done

<nckx>Yes, delete, not remove, I confuse the two.

<parnikkapore>how is it?

<junkyard>now it's complaining that xorg-server is being supplied twice because lightdm service extends xorg, but if i remove xorg, guix will start missing variables lightdm is not extending

<nckx>Ones that can't be passed through its xorg-configuration field?

<junkyard>set-xorg-configuration

<parnikkapore>junkyard: Add `lightdm-service-type` as the last argument of `set-xorg-configuration`

<parnikkapore>ACTION agrees that this really should be better documented

<ennoausberlin>Hello guix. I wonder if someone uses guix inside gitlab CI?

<junkyard>parnikkapore: still saying it's unbound, probably missing an extend for lightdm or an import

<junkyard>either way, i need to run some errands, thank you to everyone who helped

<junkyard>i'll keep working on it later

<kkcd>How do I properly generate the hash of a commit on github? I've tried guix download -f base32 https://github.com/user/repo/commit/hash, to no avail; guix package is telling me I've got an incorrect base32 character.

<nckx>Hi kkcd. First of all, the ‘base32’ used in Guix package definitions isn't base32 as it's known here on earth. It's a special nonstandard flavour, designated ‘nix-base32’ in ‘guix download --help’. This format is the default so you can omit -f. Secondly, to hash a directory tree (rather than a whole file), run ‘guix hash -rx .’ in a clean git checkout that you obtained with ‘git clone’.

<nckx>(Nix tweaked the alphabet to reduce the odds of hashes containing naughty four-letter words, such as ‘guix’.)

<kkcd>CRAZAYYYYY

<kkcd>It worked. Neato. Is there no future where guix download can automate that?

<singpolyma>kkcd: it's maybe not the right way, but if you want it semi automated you can run the build with a wrong hash and it will tell you what the right one is ;)

<kkcd>Aha. Looks like my method was wrong anyway, and that piece of advice just came up on screen in a form, anyway, singpolyma. ;D

<nckx>A ‘guix download’ that can handle more than a single HTTP GET would be nice.

<singpolyma>nckx: yes indeed

<Altadil>Hi, I’m having a weird bug in Guix System: some clicks related to windows, like trying to move them, cause the whole display to lag. Has anyone else had this ? I’m on Gnome Wayland and it never happened before yesterday (I did an upgrade the day before).

<Altadil>What’s even "funnier" is it seems to be getting worse over time…

<apteryx>hm, qtwebengine is "fun" to upgrade...

<ulfvonbelow>is it nearly as fun to upgrade as it is to build?

<apteryx>in the same bucket of fun

<apteryx>I'm not passed the huge snippet yet, with bundled libs having moved around, removed, or *gasp* added. To be known later when the 1 hour long build fails.

<ulfvonbelow>it's enough to make you start wondering about recursive guix daemons

<ulfvonbelow>so that the builder can split up the build into a bunch of sub-derivations that persist

<apteryx>or wank the qtwebengine package source, then 'remove[TAB]' in the COMMIT_MSG buffer ;-)

<lilyp>wank the source?

<apteryx>C-w in Emacs

<kkcd> https://i.imgur.com/oxo9SB8.jpg Does guile do ' shorthand?

<lilyp>we don't typically quote #t in that manner

<apteryx>lilyp: maybe I dreamt the historical reference of the C-w naming, I can't find it. And I now see how this word could be inappropriate, after searching around. Hm.

<apteryx>made sense in my mind with the playful 'yank' used for pasting

<lilyp>did you mean 'yank'?

<apteryx>the inverse operation (cut/kill)

<lilyp>ahh, i see 'wank and yank' as it were

<nckx>Weird point to re-enter the chat.

<nckx>lilyp: So the emacs-team job vanished?

<lilyp>I think so.

<lilyp>Maybe I only allocated one for gnome-team and never emacs-team

<nckx>All of this -team stuff looks ephemeral, apart from rust-.

<nckx>Did you add it through the GUI? (Question applies to gnome-team if you think emacs-team might've been a meth dream.)

<lilyp>gnome-team is actually there and yes, I'm doing gui only

<nckx>I'm almost positive that there was no deliberate action to communicate re: emacs-team.

<nckx>Yes, gnome-team is fine.

<lilyp>yeah, sorry for the noise

<nckx>There's no mention of emacs- in the logs.

<nckx>NP. Could've been a fun mystery.

<lilyp>how can I match a package by exact name?

<apteryx>in what context?

<lilyp>cuirass, but don't worry, I got a workaround for emacs :)

<RavenJoad>Is building the installer supposed to fail when you pass the -L flag?

<apteryx>OK!

<Hmmf>Hello. Do you guys know what fsf-free is for?

<Hmmf>It's for packages that follows the fsf recommendations but aren't listed?

<Hmmf>Sorry, I meant, in the implementation of guix licenses

<apteryx>lilyp: gnome-maps looks promising but routing seems to crash in libsoup

<xelxebar>next4th: Do you have a package def for blinkenlights? I just made one. Annoying that the configure script doesn't recognize --enable-fast-install.

<apteryx>any idea why?

<apteryx>xelxebar: if you have the autoconf's .ac source, you could regenerate it

<apteryx>(by adding a phase deleting the 'configure' script, and the needed inputs)

<nckx>Hmmf: Yes. https://git.savannah.gnu.org/cgit/guix.git/tree/guix/licenses.scm#n773

<xelxebar>apteryx: Oooh. I like the way you think!

<Hmmf>nckx ok I get it. The comment is clear but I needed a confirmation. Not a native speaker here… Thanks!

<apteryx>milestone; qtwebengine 6.5.2's configure phase passed

<nckx>(guix licenses) is not an exhaustive list, more a measure of popularity.

<lilyp>apteryx: crash as in application crash or crash as in "not doing X" where X is a task?

<apteryx>it crashes

<apteryx>not as easily reproducible as I thought though

<apteryx>there are other things that crash regularly in our current gnome

<apteryx>such as when using the gnome-settings panel and trying to add a printer, IIRC, or adjusting the color

<lilyp>I think you can get it to crash by zooming in or out quickly enough but that's the extent to which I've researched it

<lilyp>"adjusting the color"?

<efraim>rust-team was added in the maintenance repo

<lilyp>as for "our current gnome" in general, we're again way behind the release cycle, so there's quite possibly stuff fixed in newer versions of these applications that we just haven't seen yet

<apteryx>lilyp: I don't have it in front of me but relating to color calibration, colord

<lilyp>I wish I had the hardware to play with colord

<apteryx>lilyp: yes. I'm particularly looking forward getting rid of the webkitgtk-with-libsoup2 package

<apteryx>as latest GNOME requires all core components to use libsoup3

<lilyp>so do I

<RavenJoad>I can build the installer just fine without the -L flag. On guix 6a91d4b8e, I get 79gmlwqgfvclr40qq96278ya2njpj7r1-image.iso. But as soon as I add -L, I get "Wrong type (expecting resumable continuation): #<vm-continuation 7f32c3283a90>"

<apteryx>efraim: bordeaux looks good on https://qa.guix.gnu.org/branch/rust-team; are you still working on fixing something or are we good?

<podiki>apteryx: I've used colord, but not gnome and didn't notice any crashes; i'd have to look more carefully at my desktop though

<reed0>Hi all. I'm trying to get the Guix package manager working on a fresh install of Fedora. I installed it through the official "guix-install.sh" script. After install, running any variant of "guix pull" yields the following "error: guix pull: error: remounting /gnu/store writable: Permission denied"

<mirai>lilyp: is there any test/program in particular you want to run that requires a colour calibrator?

<reed0>I've tried "guix pull", "sudo guix pull" and "sudo -i guix pull". All give the same result

<efraim>apteryx: I was hoping to have more built first so I could compare it between the two

<efraim>I hadn't planned on any changes before merging, just wanted to make sure it was "good"

<nckx>reed0: Running ‘guix’ as root won't help, it's the daemon that's throwing that error. Could this be an SELinux problem? I don't know where those would be logged, but I see Fedora and I think of SELinux.

<nckx>Did you install the policy?

<nckx>(Note that it's just as likely as not to be outdated even if you did; it's not heavily maintained.)

<reed0>From searching, it does seem to be related to SELinux. I used all the default settings for the install script. Looking at the official documentation, it suggests that the script should handle the SELinux policy. I'll be honest, I don't really know anything about SELinux

<nckx>TBH the policy is maintained by one person and I don't think that person likes it very much.

<nckx>A common suggestion is to run ’sudo setenforce Permissive’ to disable it, but that's not a recommendation from me.

<nckx>If you chose Fedora for the NSA's secure SELinux technology, maybe don't do that. But if you do, your system should be no less ‘insecure’ than the majority of distributions which don't enable SELinux at all.

<reed0>Makes sense. I'll just disable it for now, then

<lilyp>mirai: I'd like to have consistent wallpaper colours between different screens

<nckx>reed0: Okido. It's not persistent, so if you decide that you don't like this Guix business one bit you'll be back to Enforcing on the next reboot.

<lilyp>and mere eyeballing the numbers only gets you so far

<mirai>aah, I know this issue :)

<podiki>a quick colord test I know is darktable-cmstest (from darktable) which will show what profile is loaded and with x atom

<reed0>nckx: "guix pull" works now. I do see in the documentation that on foreign distros, you need to run "sudo -i guix pull" to upgrade the build daemon. Should I do "sudo -i guix pull" every time before do "guix pull"?

<nckx>Sure. Not a bad habit!

<mirai>oddly enough, a colour calibrator might not be enough as I can crank the red component of one of my screens until the white has a red tint and the calibrator will still say "looks fine to me"

<reed0>nckx: Thanks!

<efraim>apteryx: ok, I'm going to rebase rust-team and push it to master. I went through ci.guix.gnu.org and didn't see anything obvious. hopefully it's ok

<podiki>mirai: what color calibrator do you use? (curious, as I have an old colormunki(?) that i still use)

<mirai>at one point I had a reddish white and bluish white side-by-side and they were "calibrated"

<apteryx>efraim: great! :-)

<mirai>podiki: colormunki|display I believe

<podiki>i've never done multiple monitors at the same time though

<podiki>you use displaycal or something else? i've had to use it through flatpak for now, though there is a newer python rewrite I think, I'm not sure the licensing if it bundles hardware firmware

<mirai>yep, displaycal

<mirai>well, it can be packaged if you leave any arising firmware issues aside

<gcarlos>hi, can someone point me out how would be a workflow for developing a C program on guix? I'm a bit confused in how should I use the manifests, where to put tools not related to build (like gdb and etc) and what really gcc-toolchain installs

<mirai>build tools go to native-inputs

<gcarlos>should I package the software to be able to install it for tests?

<reed0>gcarlos: this page might be useful https://guix.gnu.org/en/cookbook/en/guix-cookbook.html#Inputs

<gcarlos>and if I package, do I need a manifest/profile for it?

<mirai>as to how to precisely determine what should be native-input from input I don't have a precise answer other than "gut feeling" but perhaps others can weight in as to their precise definitions and characteristics

<mirai>gcarlos: having working tests is always good

<mirai>it lets you know that whatever you built was properly built and works as intended

<gcarlos>but all you all are suggesting implies packaging the software, sure?

<podiki>mirai: since I use displaycal directly like once a year (at best) to reprofile, other than using it to load profiles I haven't gotten around to looking at packaging. though it is on that long imaginary list :)

<lilyp>native inputs are inputs that are run at compile time

<singpolyma>s/compile/package build

<singpolyma>Which may involve compiling depending on source ;)

<lilyp>right, sorry

<lilyp>package build = compile + test + install … after all

<ngz>Hi Guix!

<nckx>o/

<mirai>gcarlos: yes

<ngz>Hmmm. Would anyone know what `आलोक' copyleft license v1.0+ is?

<ecraven>that spells "aalok" or "aaloka" in hindi, I believe

<ngz>ecraven: Thanks. So it would be the Aalok copyleft license v1.0+. I guess fsf-free is a good enough approximation.

<ecraven>I've tried google, no luck finding anything with "aalok" or "aaloka"

<ecraven>maybe this? https://www.ctan.org/texarchive/macros/unicodetex/latex/aalok

<ecraven>marathi then, not hindi

<gcarlos>what's the files sourced by the shell from guix shell -CF?

<podiki>what do you mean? without any other arguments would be a guix.scm if it exists and is authorized

<gcarlos>I'm asking about the shell specifically

<gcarlos>what the resulting shell actually source

<gcarlos>say, /etc/profile, etc

<gcarlos>for example, i know that it source some file that changes the PS1 to put [env] on it, but i don't know where is that file

<nckx>Nothing.

<nckx>Bash doesn't source anything to set PS1.

<gcarlos>so why we have specifically the custom PS1 after run guix shell?

<nckx>To make it clear that it's a Guix environment?

<nckx>I'm not sure I follow.

<nckx>PS1 is an environment variable, there's no need for to source anything to set those.

<gcarlos>so it source something to set it PS1

<nckx>No…

<gcarlos>so the guix shell set it?

<nckx> https://git.savannah.gnu.org/cgit/guix.git/tree/guix/scripts/environment.scm#n869

<nckx>Bash inherits it, it doesn't ‘load’ it through sourcing or other nefarious means.

<jackhill>what does "guix archive: error: path ‘/gnu/store/a20jlm2ngk5xhwsv89008pli8x6ydmfa-ffmpeg-jami-6.0’ is not valid" mean? Is that an authorization problem?

<gcarlos>hmmm, okay, i understood

<gcarlos>thx

<nckx>Xmake is a build system that downloads its own binaries at run time. How can you be so bad at building things.

<Hmmf>Sometimes admitting failure is better than just failing :D

<nckx>jackhill: I've seen it mean (1) the path is a fixed-output derivation that contains references, IIRC? (2) $something's changed between your Guix databases' view of the store, and the store. A ‘guix gc --verify=repair’ tends to fix those. You can use ‘repair,contents’ if your storage is fast enough and/or you have the time.

<nckx>Forgot to point out that in this case, it's not (1).

<nckx>I guess it could also be caused by just the right kind of networking error (because those seem able to trigger any bug in Guix), so if you haven't yet: retry.

<jackhill>nckx: haha. Well, I alrady did contents repair, and I'm pretty sure the archive isn't corrupted. I wonder if this is the same reason substitutes aren't available for libjami

<nckx>They aren't?

<nckx>I just guix copy'd that file name above from berlin, to test.

<nckx>Oh, missed the -ffmpeg-

<nckx>(Still, there's nothing inherently invalid about that item.)

<jackhill>nckx: nope, I haven't been able to, that's why I'm trying guix archvie --export | guix arvhive --import https://logs.guix.gnu.org/guix/2023-08-11.log#161521

<mirai>what does the #:search-paths argument for a build-system do?

<nckx>jackhill: guix archive --export …ffmpeg-jami-6.0 | ~ The Internet 🌈 ~ | guix archive --import worked fine here.

<nckx>I'm not rubbing it in, just pointing it out. I swear there's a difference.

<jackhill>nckx: ok, let me try. The actual things I specified to archive were libjami and jami. I tried both with and without grafts

<jackhill>nckx: when I exported just the full ffmpeg path, I got "guix archive: error: path ‘/gnu/store/6fba2v1qmy9ays43m2pbda5hikwbpi6q-libva-2.19.0’ is not valid" on import. I don't know why my systems are always cursed!

<jackhill>anyway, my original question remains: why, if the build was sucessful on CI can jami not be substituted.

<efraim>jackhill: if you keep on having those issues you should probably repair your store

<jackhill>source or destination?

<nckx>The side throwing the error.

<jackhill>I did a `sudo guix gc --verify=contents,repair` and it came back clean on both ends.

<jackhill>(althought in the past repair hasn't actually been able to repair, but that's a different bug)

<nckx>Hm, and run a full GC too.

<efraim>oh, try 'guix archive --export --recursive /gnu/store/foo'

<efraim>with the recursive flag

<nckx>Oh no.

<nckx>That would do it.

<nckx>I'm so used to adding --recursive it didn't occur to me 🤦

<nckx>guix archive is a little low level & doesn't pull in dependencies.

<jackhill>oh, user error. Ha! Sorry!

<jackhill>🤦

<efraim>at least we figured it out!

<nckx>Well, user using the semiautomatic footgun 2000 without watching the 2.5h instructional DVD, more like.

<nckx>I'm building jami on berlin. Often, the problem is ‘just’ Cuirass not feeling like starting any builds today, and there's nothing broken about the underlying packages. But it's still building qtbase@6, much can go wrong still.

<jackhill>usually I just use `guix publish` but these two machines don't have a good networking path between them

<nckx>guix archive + zstd + netcat can be pretty sweet.

<efraim>I never considered compressing the output of guix archive

<jackhill>nckx: thanks! Per earlier discussion, there may be a timeout issue with one of the tests, but it's weird that ci has one of the three outputs available (according to weather)

<nckx>It compresses pretty well.

<efraim>guix guix copy use compression?

<nckx>SSH compression, which is zlib.

<efraim>I thought you had to enable ssh compression with -C

<nckx>jackhill: Yeah, that's a contraindicator for test failure.

<nckx>efraim: This is years ago, but I thought I remembered it being enabled by Guix…

<nckx>Don't quote me on that.

<efraim>WELL AKSHUALLY the ssh man page says gzip

<nckx>I was confused then myself, and thought it wasn't, and Ludo' said it was, and I believed them, so if it's a lie I'm the real victim here.

<lispmacs[work]>hi, emacs-guix keeps throwing in the deploy.scm file due to this "#~" symbol:

<lispmacs[work]> https://bpa.st/UWSQ

<lispmacs[work]> https://bpa.st/DMVQ

<nckx>efraim: I thought zlib was the gzip algorithm with less frame overhead. Please leave some of my illusions intact.

<lispmacs[work]>am I running the wrong version of guile? (3.0.9)?

<lispmacs[work]>or is #~ a guix thing?

<nckx>It's reader syntax for gexp from (guix gexp).

<lispmacs[work]>hmm, it appears that deploy.scm is using that module

<nckx>Very Guixy, but if module imports are being honoured it should never be undefined within Guix itself.

<lispmacs[work]>the exception is thrown with command M-x guix c (which is guix shell commands)

<nckx>ACTION reproduces the error. ☹

<lispmacs[work]>are emacs-guix bugs reported in the guix bug tracker, or...?

<nckx> https://issues.guix.gnu.org/55013#3

<nckx>I don't know if this diagnosis is correct: https://issues.guix.gnu.org/57352

<Guest28>Would 512MB of RAM be enough to run Guix system?

<lispmacs[work]>Guest28: with or without a desktop environment and a Web browser?

<Guest28>lispmacs[work]: Headless server without any desktop or web browser.

<lispmacs[work]>I would think so in principle, except I remember reading somebody having trouble getting his 64-bit kernel to boot with only 512MB

<lispmacs[work]>but I'm not sure how much memory it will take to build your profiles when you do package or system updates

<nckx>Guest28: With more swap than RAM and a lot of patience (guix itself likes RAM—a lot) it's theoretically possible. It won't be pleasant to guix pull or build packages from source.

<apteryx>ACTION grumbles... `build' failed after 1770.3 seconds

<lispmacs[work]>apteryx: you blinked, didn't you?

<lispmacs[work]>it only works if your eyes stay glued to the screen the entire time

<apteryx>hehe

<Guest28>Alright thanks.

<apteryx>was there a reason *not* to have /run on a tmpfs on Guix System?

<RavenJoad>Guest28: I am about to migrate my website to Guix system and it will use 1GiB of RAM. Using guix deploy, it is very possible. Initial install and first reconfigures will need to be small though.

<nckx>jackhill: berlin should have a substitute for jami now.

<nckx>If not relevant for you, then perhaps for someone else.

<apteryx>qtwebengine makes it to 23922/27300... suspense

<apteryx>haha, it failed after the main compilation target was done

<mirai>apteryx: other than an extremely obscure issue with GDM&wayland that has long been fixed, no

<mirai>ah wait, I've misread your message

<mirai>thought you were talking about /tmp

<mirai>afaik /run should be volatile if I'm recalling FHS right

<mirai>almost every distro has it as tmpfs anyways

<mirai>we're the ones missing out :)

<mirai>Does anyone have any idea what 'ages' and 'full XML tool chain' actually quantify to? <https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/version-control.scm#n249>

<civodul>mirai: hmm looks like the XML tool chain is mostly there already (libxml2, xslt, docbook, etc.)

<civodul>"ages" might be like 10mn

<mirai>hmmm… might be worth a shot at building from source then

<civodul>yeah

<mirai>atm I'm reworking the (docbook) XML handling

<mirai>right now the series is hoovering at ~23 patches but there's still some packages that are yet to be simplified from their workarounds

<mirai>hopefully with it docbook & its XML friends will simply "work" without any patching or custom phases (no more chasing angle-bracket looking rabbits)

<apteryx>uh, /gnu/store/nqq5lm5vqpp5aajc2809vp2srxp1v9j0-qtwebengine-6.5.2

IRC channel logs

2023-08-14.log