<kiwibytes>nckx: I am just trying once again now, but it was always one driver whitch was already been loaded just before the reboot...
<kiwibytes>I don't know, i think i also have to maybe load a non-free firmware driver for the embedded graphics. It is not as easy as i thought it would be.
<kiwibytes>I have not that much experience to debug this pile of shit.^
<kiwibytes>Maybe it was "just" a bootloader problem, but GRUB alone has a lot of options and until now i haven't had such problems with it.
<kiwibytes>I think it was a hardware error. "TSC 0 ADDR feb00004" "PROCESSOR 2:70f01 TIME 1689295014 SOCKET 0 APIC 0 microcode 7030106" After that there was a message "pthread_getattr_np or pthread_attr_getstack failed for main thread" ... AND then ... "Couldn't read /proc/stat" ... The last message i saw was udevd: no sender credential received, message ignored
<ChocolettePalett>I have an issue with LibreOffice (likely caused by how minimalistic my environment is): firstly it was shutting down due to lack of "GSettings desktop schemas", so I installed both "gsettings-desktop-schemas" and it's "-next" variant after failing to run it run it again. Though now it fails because LibreOffice can't find "org.gtk.Settings.FileChooser" setting schema.
<ChocolettePalett>To be honest, I am lost and have no idea about what to do because this problem doesn't seem to be mentioned on guix-help mailing archive. Did anyone have a similar problem or does anyone know how to resolve it?
<ecraven>how do I show all files that a package installs? for example, s7 ;)
<vagrantc>"guix shell" is definitely the way to go if you want to "uninstall" things immediately after running something
<vagrantc>that is essentially exactly the use-case ... it creates a one-off environment with the desired packages available and can run an interactive shell or arbitrary commands
<vagrantc>although to actually delete them from the filesystem after the fact, you would also need to run guix gc ...
<vagrantc>but they are only ephemerally "installed" in the environment inside guix shell
<ecraven>that's fine ;) thanks, just checking out which Schemes already exist in guix and which I'll need to create derivations for. also, racket segfaults, but not when run under gdb :D is there a central place to report a bug about this? I'm on arch linux, just did guix install racket, then running racket segfaults.
<vagrantc>sounds worth reporting to firstname.lastname@example.org
<ecraven>I'm trying to write a simple package (running nasm then gcc to link) for Bones (http://www.call-with-current-continuation.org/bones/), and it fails. |builder for `/gnu/store/y0x90n0zr0x2r480q08vmm4452v8zqrb-bones-8.drv' failed with exit code 1 how can I tell guix to show me more details about *how* it fails?
<pjals>-K keeps failed build directories in /tmp/ ;^)
<ecraven>hm.. I think I'm in over my head here, nasm runs fine and creates bones.o, but now I need to link that with gcc... on other systems I'd run `gcc -no-pie bones.o -o bones -lrt' but I have no idea how to properly run this on guix to make it find crt1 and stuff...
<pjals>cant you just do gnu-build-system? you have a sane makefile, right?
<ecraven>of course not :D but I can try to add one...
<nckx>ecraven: <only what I directly installed?> Yes, in this case. The way random packages get directly ‘pulled into’ the current profile is through propagation, which undermines certain Guix features. The racket package doesn't propagate anything, so you're safe here.
<cbaines>right, I removed some "cached" zstd nars from bayfront to free up space, but this turned out to cause lots of problems
<cbaines>I still need to change the caching concept in the nar-herder to match that of Guix, which is when you serve a narinfo, you make a best effort attempt to continue to serve all the mentioned nars until the narinfo TTL expires
<cbaines>nckx, recent versions of Guix should try to fetch the lzip nar if the zstd one can't be fetched, and removing the cached narinfos will work around this
<bienjensu>Hi, I'm trying to build TrenchBroom but I need to tell vcpkg using an environment variable to use system binaries instead of trying to build them itself. How would I set an environment variable in a package declaration?
<bienjensu>I tried putting it in `configure-flags`, but its not a cmake option obviously.
<jpoiret>janneke: you mean rebasing? Yes I did mean to do that at some point
<nckx>bienjensu: If an environment variable truly is the way, then #:phases (modify-phases %standard-phases (add-before 'configure 'use-system-binaries (lambda _ (setenv "FOO" "bar"))) …) ; is the way.
<bienjensu>nckx: Thanks, vcpkg still can't find curl though, despite it being in `native-inputs`. Not sure what the problem is.
<nckx>When can't it find curl? During build? Then you'll have to peek at the build system scripts to see how they are buggy, and likely ignoring/clobbering $PATH.
<nckx>bienjensu: I'd add an ‘echo $PATH;’ (in a quick & dirty substitute* phase) to bootstrap.sh just to see what's going on, and if I'm up the right tree. It might even give you something to grep for.
<mirai>ecraven: forget that 'trivial-build-system' exists
<nckx>lissobone: I did not look at the build system, but setting (string-append "CPPFLAGS=-I" #$(this-package-input "libtirpc") "/include/tirpc") in #:configure-flags or so is usually about the rightest way.
<nckx>I.e. modify the search path, non the search string.
<pjals>oh wow, why did i not think of that! im so stupid!
<podiki[m]>i guess for purposes of rebuilds will need to merge tex branch into mesa-updates? i'm not worried about breakage so much as getting our substitute coverage ready
<podiki[m]>mesa-updates is just 2 commits directly to mesa, so easy enough to handle
<ngz>podiki[m]: I don't think the order matters. But, yes, waiting for a good coverage is the longest part of it.
<podiki[m]>i guess i could do the merge into mesa-updates so it can start building, and then maybe cleanest to just cherry pick the mesa updates to master when we are ready?
<podiki[m]>i don't see the need for the actual merge commits (seems messy for mesa-updates since it is so little)
<mirai>apteryx: I don't think its going to be easy to get fstrim-service-type in %base-services
<podiki[m]>:( just tried to push some commits for Pierre but i lost the author when going from my local branch to master
<mirai>there's no easy way to “add some-service-type but only if this isn't hurd”
<podiki[m]>copyright line was added at least; anything else i can do after the fact?
<mfg[m]>does someone know the minimum amount of packages necessary to use lualatex in guix?
<cbaines>ngz, do you know what change led to the full rebuild? I guess it's possible that something changed on master to make that happen, but only if the changes on tex-team-next used something that it wasn't using before
<podiki[m]>i think I noticed some grafts locally (not on tex branch) for something related to cups? could that be it?
<ngz>cbaines: Unfortunately, I don't know what happened. I added a few TeX Live packages just before the merge, but nothing core. So it surprised me.
<ngz>mfg[m]: Technically, you only need texlive-bin.
<ngz>mfg[m]: But I think once the TeX Live update is done, you can simply install texlive-collection-luatex.
<cbaines>it might be worth trying to change that comment back locally, and see if you get outputs matching what QA has built
<ngz>cbaines: Yes, I reworded a comment. Do you mean this would trigger rebuilds?
<Guest9331>hello I'm new to declarative system configuration and wonder (without any troll) what are the pros and cons of guix over nixos (number of packages available put aside) I could not found any resource and the matter.
<cbaines>ngz, I think it can, since it seems like the build system files are in the store verbatim, rather than being read/written as an sexp
<cbaines>which is why QA when from showing quite a few things built, to now pretty much nothing built, as it's looking at 118811f0b6ce20776bdd51ecbc3049c4a50c97a9
<cbaines>maybe the time lag between pushing to a branch and QA updating has caused some confusion here, I'm not quite sure if this is displayed well
<ngz>Yet, this change happened 32 hours ago. I understand some delay is necessary for QA to switch HEAD, but this switch happened just now?
<cbaines>ngz, I think QA would have updated sometime yesterday afternoon/evening
<ngz>I mean: yesterday I saw this "everything unknown" state, then numbers changed, then I see this everything unknown state again. I am puzzled.
<ngz>Of course, I changed nothing in the meantime.
<cbaines>hmm, what do you mean by "then numbers changed"? I'd expect it to switch to everything unknown yesterday, then remain that way
<ngz>Not at all. A few hours ago, more packages were being reported as built, and dispatched throughout the various categories (failure, block, etc).
<ngz>IOW, there were less packages in an unknown state.
<cbaines>not sure what would cause that, I think what I'm seeing QA show now is representative though
<ngz>Fair enough. I give up on this "hiccup". So, now I have two options: either I reinstate the old comment again and wait 24 hours for the build process to catch up, or I don't touch anything anymore, and wait ?? hours for the build process to catch up. :)
<cbaines>ngz, from what I can see locally, changing the comment back is definately the way to go
<ncd>I've returned with another quandary. Inside of `guix shell tmux`, tmux loads just fine, but outside of that (I've used `guix package -i tmux`), I get an error about the locale/lang var.
<jpoiret>I don't think we can build anything hurd related with that older mig now though
<ngz>cbaines: Well, this is embarrassing: I tried to re-instate the old comment, but I cannot push anymore to Guix repository. "make authenticate" fails with error "In procedure verify: gcrypt: incorrect length". Of course, it never happened on any of the previous iterations.
<bjc>it's not at all. most systems have little use for it, though, because config files are located in standard places. guix makes tracking them down a lot harder, so the ‘configuration’ action is uniquely helpful