<apteryx>bricewge1: there's another error though: guix deploy: error: failed to deploy raisin: ~A: ~S
<apteryx>interestingly the message is not properly shown
<gnutec`>ryanprior: I had a problems with gdm after upgrade to kernel 5.4.12. I talk to the e-mail of Ludovic (firstname.lastname@example.org). But the problem was solve with new updates. Just wait! If what you did is good, they will add. Or you can share your scheme definition by your self.
<apteryx>I think I know that one, it happens when trying to restart the nfs-server or something related
<ryanprior>Of course, if I start packaging software built with v, then those will only be available in my repo as well, there would be no point submitting them upstream if the compiler isn't available XD
<timothy_>Numbers are not rendered in IceCat for me. This even happens in the address bar. If I visit 'covid19.com', I see 'covid .com'. I am using i3 so maybe its an i3 configuration error?
<NieDzejkob>timothy_: you're missing some fonts. Install font-liberation and/or font-dejavu and run fc-cache -fv
<mbakke>I've used Ganeti for eons and have missed it in Guix, but did not dare trying to package it until now.. it's a complicated beast consisting of many different daemons, and written in a mixture of Python and Haskell.
<mbakke>it's kind of like VMware, except more reliable (especially in a cluster setting), and without a pretty GUI
<vidak`>i read online that some people with an AMD RX580 graphics adaptor had no issues getting all their hardware working, but i found it necessary to, sadly, install some non-free firmware in order to get my RX550 adaptor working
<bonz060>leoprikler: like if there's a guix profile that's looks like `guix archive --manifests` and then later ingest it vis-a-vis: `guix package -m manifest.scm`. Does guix provide an inbuilt CLI flag to output a manifests.scm file instead of writing a script that does that? That's what I mean.
<bonz060>leoprikler: I'm thinking it's a convenient that alot of people would want. At some point when moving machines, you'd research how to reproduce your system right? At that point, it would convenient to have an inbuilt tool that generates the manifests file for you
<Bryophyllum>NieDzejkob: Thanks. To clarify, do you mean that your /boot directory is separate from /?
<NieDzejkob>Bryophyllum: Yes, I mount the ESP partition at /boot/efi
<Bryophyllum>NieDzejkob: Oh. /boot/efi, not /boot. Gotcha. Speaking of which, isn't an ESP partition at /boot/efi a requirement? Like, I know the /boot itself can be a fat32 partition, and this fact alone makes a separate mountpoint for the ESP partition redundant, but I personally think that /boot whether on an external partition or not, should be on more corruption resilient FS, such as ext4, on UEFI systems
<guix-vits>oliverp: I'd read someone told on StackOverflow that "microkernel is not for faint hearths" or so. Though me too want it.
<nckx>That's meaningless without context. Hacking on a monolithic kernel like Linux is hardly for the faint-hearted either, and potentially more dangerous.
<janneke>i for one was amazed how well it works, a year or so ago
<janneke>i'm a big fan for working towards the changes you'd like to see happen
<oliverp>janneke: yeah its super that someone doing is efforts with regards to try provide Guix Hurd-wm image
<oliverp>janneke: +1 well I'm writing on something, that might could help at least a little bit
<oliverp>janneke: and while its not ready for publishing yet it could in a week or so maybe
<oliverp>jannkeke, maybe I could connect back then for some kind of feedback
<janneke>that's great; being involved does not necessarily mean to write code
<janneke>oliverp: sure, please do -- have you seen #hurd?
<nckx>raghavgururajan: Not on wip-desktop? Could you paste the package? ccache is meant to speed up incremental compilation (and it does so wonderfully) but makes no sense in a chroot that's thrown away after each build. If by default wpewebkit won't build without ccache I'm sure it can be disabled.
<oliverp>janneke: thanks. well yeah while I have a cretin understanding of C, writing code is what I consider my strongest skill
<Bryophyllum>guix-vits: It is. What I meant is that mounting the ESP partition at /boot/efi is compliant with the spec, and should be preferred over a FAT-formatted, separate /boot partition, as it usually holds kernel and initramfs images that I wouldn't trust FAT with
<Bryophyllum>Though, Guix seems to not store those on /boot, so it doesn't matter
<bonz060>janneke: when working on hurd, do you run it on a VM? How'd a noOb(I primarily have a tonne of wed-dev experience) start out? That's something I'd like to start exploring but I don't have an idea of how to start :(
<jlicht>general question on G-expressions, but how would one make packages with native-search-paths 'usable' in the context of the g-exp? I think this is nicely solved for guile modules and closures, but is there some way to generalize this to e.g. EMACSLOADPATH?
<jlicht>pkill9: people who have a need for a configuration file and think "I know! I'll use xml, that'll make life easy!" have plenty of things wrong with them ;-) \s
<leoprikler>"Hmm, I need a configuration file... better write my own language while I'm at it."
<pkill9>they have a browser-based configuration, except it doesn't render with a CLI browser. they have a REST API, which is annoying enough but you also need to create an API key. There is an 'stcli' program but not only did it not accept the syntax (if i even was using it correctly), but apparently it's deprecated
<pkill9>and yea, on top of that the config file uses XML
<nckx>raghavgururajan: To answer your earlier question: ccache is a compiler (‘cc’) cache. It replaces gcc (the normal way to use it is to create a /usr/local/bin/gcc → /usr/bin/ccache symlink, which precedes the ‘real’ GCC in $PATH). When you call it the first time, it will simply call the real GCC, producing the exact same output. But it will also save the output so the next time you call it with the exact same arguments, pwd, etc. it can si
<nckx>mply (and immediately) return the exact same output without compiling everything again.
<leoprikler>the thing is, you don't get the same package in a build, that doesn't fail at 67% deterministically
<leoprikler>so even if we had a build cache, it would probably not do what you'd expect it to
<nckx>raghavgururajan: Yes, that's exactly the problem that ccache solved for me on Exherbo. Even a minor version update would share 99% of the previous source files so most package upgrades went a lot faster with a full cache.
***jonsger1 is now known as jonsger
<nckx>However. There are edge cases (I had to rm -rf my ccache once in a while to get rid of ‘weird’ errors) and there are some serious trade-offs that I don't think belong in Guix.
<raghavgururajan>leoprikler, Ah, gotcha! If say, foo.o and bar.o was compiled at 3% and over-al build fails at 10%. If those *.o files not gonna be changed in rebuild, we can reuse those cached files right?
<nckx>Guix gives me peace of mind: almost every time I think Guix screwed up/got confused, I look again, and it turns out it was right and I was confused 🙂 That's extremely valuable. You'd lose that peace of mind and the nagging state gremlin (whispering ‘maybe you should just reinstall…’) on my shoulder will return.
<leoprikler>how do you ensure, that everything leading up to the 3% build is the same between those two builds?
<raghavgururajan>leoprikler, nckx: For example, a while ago, I was building a package. It failed at 95% due to missing glu.h. All I had to do is rebuild with glu as input. Here, all the files that were compiled before 94%, didn't depend on glu.h. So those 94% of compiled files could have been reused right?
<leoprikler>no, because your build system could have done something weird if it detected glu, adding additional sources to the files that are compiled
<leoprikler>adding -DHAVE_GLU so that the files that you do compile compile differently
<leoprikler>what could help was if you used GWL as build system and we had (guix build-system gwl), which specifically shares the GWL cache with the build
<nckx>raghavgururajan: It does use hashes. It also looks at command line flags and variables like CFLAGS and working directories and …. leoprikler's scenario is probably too trivial to confuse ccache, but any cache makes tradeoffs, and Guix doesn't, so the two aren't compatible. GWL is a much better (and ‘native’) approach that a magical ‘cc’ binary.
<raghavgururajan>leoprikler, Hmm, but build-system could not have done something to files that were compiled before 94%, because their respective .c files did not have #include glu.h
*guix-vits "the Fairies wear boots, and You got to believe me... I tell You no lie.."
<nckx>guix-vits: I'm not sure I understand the question. HOME is set (and I believe exported) to "/homeless-shelter" in the build environment. Shells use the value of $HOME to expand ~ (~/foo is just syntactic sugar for $HOME/foo).
<nckx>So if you change $HOME it will change ‘echo ~’ as well.
<nckx>mwelt: Wow, I don't have time to answer that can o' worms I'm afraid 😉
<nckx>raghavgururajan: OK, that might take a while. See y'all in a few hours.
<mwelt>leoprikler: ah i c. This is actually not what I want. I want to be able to boot this usb stick from another hardware setup...just like the install iso of guix works. So am I able somehow to install grub just on the mbr of the usb stick?
<leoprikler>you could try grub without efi, that tends to work out (at least for me)
<mwelt>raghavgururajan: actually I am not 100% sure about that, but you might be right, that this is only a partition thing. But there must be some way to uniquely identify the hardware component itself
<mbakke>lfam: font cache issue perhaps? font-dejavu is the grafted fallback in fontconfig when no other fonts were found
<lfam>mbakke: I deleted '~/.cache/fontconfig' and '/var/cache/fontconfig', ran `fc-cache -rfv /usr/share/fonts ~/.guix-profile/share/fonts`, but it still doesn't work
<lfam>I also tried updating with --no-grafts which should avoid the fontconfig change, right?
<mbakke>lfam: yes, --no-grafts should make it fallback to the broken gs-fonts
<tmck>I've just installed guix system alongside debian (and windows), and after manually copying the GRUB menu entry into my existing grub, I am able to begin guix boot -- but it keeps freezing during "early boot guile"(?), the last message is usually `parport_pc parport_pc.632: Unable to set coherent dma mask: disabling DMA` -- any suggestions on how to
<tmck>i removed the "quiet" argument from the guix grub entry -- with more verbose output i can see the boot reliably fails at `switching to amdgpudrmfb from EFI VGA`, looks like i am missing some firmware
<tmck>Bryophyllum the display was plugged into an RX 580, I am trying to see if I have any luck running it off my Ryzen 5/Vega now
<tmck>NieDzejkob noted, thanks! i will try that out
<nckx>tmck: Or you can add a ‘Guix’ menu entry to your existing grub.cfg that loads Guix's grub.cfg with ‘configfile’. Guix wants to manage (a) grub.cfg but it doesn't have to be your only boot loader.
<nckx>raghavgururajan: Things are building at full capacity now, I don't know how much work was done while I was travelling.
<nckx>gnutec: Yes, lzip replaced gzip as the default compression algorithm for ‘guix publish’. I think this was done because it's a GNU(ish?) project and there were bindings available (again: ?). lzip has… opinionated marketers^Wmaintainers. I don't like them. Both xz and lzip compress equally well (with xz performing ever so slightly better in my tests).
<nckx>As a user, you wouldn't notice a difference between xz or lzip in practice.
<apteryx>eh, I get out of memory failures during the tests when building a slightly modified Guile 3.0.
<pkill9>ok it wasn't too difficult to configure syncthing, i just needed to do an ssh port forward, then i could change the settings in my laptop's web browser, still sucks they make it way too difficult to configure via commandline
<mbakke>vagrantc: we should probably remove the rust dependency from ffmpeg on non-x86_64
<mbakke>or better yet, complete the aarch64 rust port
<NieDzejkob>does anybody have an idle arm server lying around? I think building rust in QEMU will take a good while...
<ngz>I'm trying to update our xmoto package. The new version builds fine, but I get texture rendering errors at run time (error message displayed when trying a game). I would appreciate if someone else could build it too and report if they encounter the same problem. The package updated package definition is at: https://paste.debian.net/1152957/
<civodul>janneke: i think that "staging" branch that "bad" is on was forked before 36640207c9543e48cd6daa92930f023f80065a5d
<mbakke>ngz: it works great, but it's 1) based on the git source, and 2) will rebuild the maps every so often, and the map generation is not great, so it might create "bad" maps (there are tests to catch this).
<mbakke>the official ufoai releases come with pre-generated "vetted" maps
<mbakke>NieDzejkob: are you working on rust 1.19, or updating the bootstrap chain in the same go?
<ngz>mbakke: Thanks. Do you think it is possible (and worth the trouble) to switch it to official release, and therefore benefit from the "vetted" maps? I assume downgrading to 2.5.0 will require additional patching.
<mbakke>ngz: yes, 2.5.0 requires a lot of patches, and according to #ufoai 2.6 was "mostly complete", so I just went for it :P
<mbakke>ngz: I suppose we could add it with a warning that it is a pre-release
<mbakke>NieDzejkob: bayfront used to have an ARM machine actually, hosted by Andreas. If you email guix-sysadmin@, perhaps he can add it back or give you a shell.
<Bryophyllum>terpri_ & nckx: Thanks for your suggestions, though, I'm afraid that programming low-level system components is out of my league. Having used Linux for a while, I grew used to compromising and giving up on things that would require a lot of work
<pkill9>mnt reform does look cool, too costly tho :(