<nckx>I think we should set a fixed schedule (every * days) and/or policy (every *or kernel bump) for reboots. We won't always follow through, but at least each missed reboot will be a decision, and something that needs a mild defence.
<lfam>Although I can't imagine it would result in a graceful shutdown
<nckx>Git error while fetching inputs of 'core': "failed to lock file '/var/lib/cuirass/.cache/guix/checkouts/pjmkglp4t7znuugeurpurzikxq3tnlaywmisyr27shj7apsnalwq/.git/refs/heads/master.lock' for writing: "
<apteryx>and then it took a long while after restart before picking up; I also had noted "pteryx seems to be busy clearing the build queue: 2021-11-25T16:34:54 Database worker unresponsive for 5 seconds (db-clear-build-queue)"
<vagrantc>haven't updated the pinebook pro since the core-updates merge, and given the state of things might wait a bit ... or build everything on the apm mustang and take it from there
<lfam>I'm looking, and epiphany depends on Rust librsvg transitively through several of its direct dependencies. Maybe these transitive dependencies all resolve to the same place, I don't know. But it won't be simple to bring it back
<lfam>Rather, we need to get rust working on aarch64
<lfam>Not a great answer but ultimately the path we need to go down
<apteryx>wip-cross-built-rust branch has a working cross built rust, but it's not statically linked (rustc can't easily be)
<vagrantc>yeah, that sounds like what i was getting at
<apteryx>so using it as a bootstrap seed would be a bit messy (it'd have to contain its full closure and use some relocation hack to refer to its inputs at another place than /gnu/store)
<vagrantc>for a language that is all about static linking, kind of ironic that it can't itself be statically linked :)
<nckx>the_tubular: Your system configuration can do anything, in the sense that it's a programme that runs as root each time you reconfigure. All Guix expects is that it returns an operating-system, but if you write code that first checks whether your partitions are xxx and invokes, say, fdisk+mkfs if they aren't, it will work. You have the full power of Guile at your disposal, limited only by your own sanity & good taste.
<apteryx>vagrantc: binary bootstrap seed would work, that's what everyone is doing, but it's far from Guixy
<florhizome[m]>maybe my thinkfan service is starting to work (I was to busy with transferring to new master yesterday to check, but it spits some stuff onto the terminal (I think that’s the kms thingy?) before the login manager pops up), or it’s just cuf, or both :) anyways, that’s great :)
<florhizome[m]>also jpoiret helped fixing sddm, now it’s only enlightenment that doesn’t work, I guess I will need to report that
<florhizome[m]>I pasted some xorg configuration into my config that broke it.
<jpoiret>florhizome[m]: i've had an issue with thinkfan/shepherd forever, on my laptop hwmon takes its sweet time to be available, and thinkfan cannot start without it. However, shepherd stop trying to restart it at some point, and the number of retries is not configurable (yet). So I often end up with no fans working when resuming from suspend or
<jpoiret>booting, unless I remember to start thinkfan manually :)
<rekado>so I would expect it to be available in gtk 4 as well.
<NicholasvonKlitz>Ah okay. Just to clarify, since I'm including gtk as a native input, I should be able to execute broadwayd prior to the check phase just by executing "./bin/broadwayd :1"? Sorry I'm a little new to this :)
<efraim>I assume it'd be something like (invoke (search-input-file "/bin/broadwayd") ":1")
<attila_lendvai>rekado, oh, i see! didn't think of that. maybe there could be multiple c-u branches? e.g. have one for such simple, certainly non-breaking change, and merge these into master more frequently than the big c-u-f struggle that needs to ensure everything works...?
<attila_lendvai>well, actually two is probably enough. one for world-rebuilding, but semantically simple changes; and one for all other world-rebuilding changes.
<mbakke>I also think the 'core-updates' approach does not scale... it would be good to have a branch with "stable" updates such as libjpeg, OpenSSL, expat, python 3.9.X etc, and merge it as part of the ungrafting cycle; and different topic branches for breaking changes, such as GCC upgrade, Python 3.10, build-system changes, etc.
<zimoun>after “guix pull”, and “guix gc”, I get this: «guix gc: erreur : entrée corrompue en restaurant l'archive depuis socket». What could be wrong?
<mothacehe>mbakke: i agree, we need to come up with a different branching organization. Could be good to start a discussion about that on the ml.
<zimoun>mothacehe, yeah! As we already discussed a couple of times. :-)
<mothacehe>rekado: yeah the openssl_x509_checkpurpose looks it is trying to access internet
<zimoun>I get this error about “guix gc” on two different machines.
<walrus_>I have a problem, after I ran 'guix pull' and 'guix package -u' as root I can't run guix as user due to what appears to be a libc mismatch. Trying to run 'guix' complains about GLIBC_2.33 not being found.
<dissent>both internal and external microphones aren't receiving anything. not bluetooth. specifics? um lenovo thinkpad l580, what else would i provide?
<civodul>rekado: nothing, just missing substitutes
<civodul>my laptop stopped halfway, pretending it needed more disk space
<dissent>Everything used to work fine on Arch. That was months ago now. It was worked before with Guix after reinstalling alsa and pulse but the cause was never clear.
<dissent>rekado: i don't think so, also doesn't work with chromium... sometimes qutebrowser does the trick.
<dissent>i've also switched from a system76 to a lenovo while still having the same issue so it doesn't seem to be a hardware issue.
<jpoiret>could you try removing the part about the alsa-service-type? it's already included in %desktop-services, if you want to modify the configuration (but you shouldn't need to for pulesaudio), you can do so with the modify-services macro
<florhizome[m]><abrenon> "in all the liveCDs I've generate..." <- how do you do that starting from a login manager? Normally I remember jump to tty and login as root.. how would that workout here?
<zimoun>I did “guix pack -RR” then copied the result on a machine I do not control. I get «proot error: ptrace(TRACEME): Operation not permitted». What is missing? A config about kernel?
<dissent>jpoiret: okay. something weird. people on the other end can hear my audio output. so my output goes into my input.
<jpoiret>zimoun: the program needs CAP_SYS_PTRACE, maybe it doesn't have it
<jpoiret>did you try rekado's suggestion about the duplex config
<rekado>dissent: my comment about icecat was directed at civodul, sorry for the confusion
<yewscion>Hello everyone, I have a quick question about hardware compatibility in GNU/Guix: On H-Node, it says that the RTL8812AE chipset works without trouble with free software. I purchased a cheap wifi card for my recent build, and it worked fine initially. But upon `guix system reconfigure` yesterday to change my keyboard layout from stock, the card is
<yewscion>no longer detected as a network interface.
<zimoun>jpoiret, I know. But many users run “guix shell”, then sometimes one run “guix gc”. The next “guix shell” is really annoying. I would like to disable “guix gc” for the regular users.
<mbakke>zimoun: you could use a TCP socket and make the /var/guix/daemon-socket unavailable -- IIRC GC is disabled when communicating over a network socket
<cbaines>things like indexes can slow updates down, so there may be things that can be tweaked there. There are also things like the fill factor for indexes and tables which can help trade insert/update performance for space on disk
<EdwardIII>hey, if you want to install guix system on qemu on an ARM guest, what are the options? build it on the host first? interested in playing with it but on mac m1. i see you can get guix actual for multiple platforms, but not guix system
<jpoiret>well, it theoretically shouldn't be. Still scratching my head about that.
<attila_lendvai>rekado_, the first error i see: .../libc.so.6: version `GLIBC_2.33' not found (required by /gnu/store/[hash]-libproxy-0.4.17/lib/libproxy.so.1), leading to: Failed to load module: /run/current-system/profile/lib/gio/modules/libgiolibproxy.so
<attila_lendvai>the ultimate error is from python: KeyError: "unknown key: 'hinting'"
<jpoiret>attila_lendvai: did you update your guix profile?
<GNUtoo>As I understand these settings are relative to the user which runs gdm (typically gdm on most distributions)
<samplet>GNUtoo: For context, I just pushed a very similar commit, and it works, but jpoiret pointed it out that it worked before. Now I’ve noticed that I must of made a mistake in reproducing your issue, because it works for without my (our) changes.
<jpoiret>samplet: it's actually af37e6bbd4a0b97c8147ccbd1548dc2e5f830466 that does it, right in the gdm package definition
<GNUtoo>(The issue is that the system.scm I use is deeply intertwined with my Parabola installation, so there is modifications and additions to do)
<samplet>jpoiret: Good find. Now what’s the story with that patch? :)
<jpoiret>looks like andy's commit is older than the patch. I don't really know why it's there, but the patch is a bit more involved, it makes GDM not search in the system dirs, but only in the current system profile
<jpoiret>i think it would be possible to have gdm working differently: have `gdm-configuration` contain a `sessions` entry which would be a list of packages (maybe just file-likes) which would have .desktop files
<jpoiret>GNUtoo: are you using a recent-enough guix version?
<samplet>If I can find time, I’ll see if I can contribute by cleaning up the GDM <-> GNOME Shell dependency cycle hacking stuff (cf. the “XXX” comment in the GDM service.
<nckx><even when> Now you're talking about a *different* error, though.
<NicholasvonKlitz>nckx: sorry but I'm having trouble understanding the error messages. When it says `Invalid preceding regular expression" #f ("(?<! |^)#.*") `, does it mean the error is in `("^ *#.*")`?
<nckx>I think it's a general ‘invalid regexp’ error, not referring to a specific subexpression.
<nckx>I don't think dynamic typing enters into it. Each substitute* clause is ((REGEXP [VARIABLE…]) REPLACEMENT). Variables are optional. The first one always captures the entire match, which we don't care about, so we give it the conventional ‘I don't care’ name of ‘_’ (this is not magic, just a variable name). The subsequent variables capture each ‘(…)’ regexp group in order. The REPLACEMENT is just scheme code: we append a newline
<lfam>The package definitions will have to be adjusted to fix that
<lfam>It's a classic case of an impossible propagation graph
<tex_milan>hi guix! how to find out why guix upgrade is trying to rebuild locally "nss" even though weather says it is available pre-build?
<jackhill>civodul: I found my static-networking-service-type problem from the other day. It was a typo; I had introduced a space at the end of the IP address. Everything I want so far is working now. Thanks again for all the work. I'm super excited to have static v6 configurations now!
<lfam>Not sure exactly, tex_milan. The build farm / CI server is currently not operational but undergoing some maintenance. So it may be that the answer to "is the substitute available" was cached, and that information is no longer correct
<tex_milan>@lfam it's been that way couple last days. can anybody at least disable tests in nss? it takes 48hours to finish those tests apparently....
<lfam>No, sorry, we aren't going to disable tests or adjust packages to work around this
<tex_milan>and can i do it myself in my config? some override?
<lfam>It's definitely possible to disable tests on your end
<nckx>tex_milan: #:tests? (and all argument keywords) is optional, defaulting to #t. What matters is ‘if tests?’ in the check phase, which will DTRT.
<lfam>I do think that skipping the tests may not be a win in terms of "finish quickly", although it depends on your goal. Many packages depend on NSS, so if you change it by using --without-tests, then those dependent packages will also change and need to be rebuilt, even if you already had built or downloaded their substitutes
<tex_milan>thanks! works. i used the same / similar things. maybe took yours :) don't remember exactly.
<unmatched-paren>nckx: there actually is already a tree-sitter patch. however, it adds the _emacs_ tree-sitter plugin, which does not afaik have a self-contained install option like nvim's TSInstall, so it needs to package the individual parsers, which i think from a cursory look at the patch needs a couple of nodejs changes
<nckx>tex_milan: By ‘context’ I also mean that $PATH could have somehow been broken so that you weren't using the right guix in ~/.config/guix/current, but an older ‘unpulled’ one. But it's hard to say after the fact.
<tex_milan>unmatched-paren: vlang, hmm. didn't know about it, definitely will look at it. looks interestingly.
<attila_lendvai>nckx, saving the patch is a lot more trouble, with updating the makefile, then not forgetting to delete the entry when you delete the patch, etc, etc...
<unmatched-paren>tex_milan: ah, vlang is a massive pain, i'd recommend you stay away from it for now until they realize that depending on the executable being in a mutable directory is a terrible idea
<jpoiret>is it common to have qemu segfault on you?
<unmatched-paren>the author appears to use a mac, which doesn't have a package manager, so i guess you can't blame them
<florhizome[m]>Does someone know how guix uses gnu mes and how it compares to debootstrap?
<nckx>Ohkay. It's subjective then. I find that less work. I still recommend shipping the patch file with Guix if you intend to commit this to Guix. The robustness argument has won out, and direct origins aren't that common anymore.
<tex_milan>unmatched-paren: oh. that's bummer. i just saw vlang vs go and it looks interestingly. thanks for warning!
<tex_milan>heh. good luck using anything like npm, modules or whatever if you really need security.
<jpoiret>also, I think that people have been told to reuse code too much, to the point where every single stupid snippet on the planet is an unmaintained go package from 5 years that serious widespread software still depends on
<florhizome[m]>jpoiret: no there also seem to be a fair amount of ppl that study “proper” compsci and use python and do ai everywhere
<tex_milan>true. my bias is industrial automation firmwares. so you end up with c++98 and 10years old libraries :)
<nckx>jpoiret: That was one of the things that struck me about the Guile (maybe, Scheme) community at first: less ‘DRY’ than was hip everwhere else.
<attila_lendvai>nckx, oh, i see. i wouldn't do that... i think even what i proposed would only be nice to use when you point to a commit in the same repo as the origin points to (i.e. a commit after the release tag)
<jpoiret>yes, i'm still mad about the official protonmail bridge app in go, but they depend on 7 years old code (!!!)
<LevyElara[m]>florhizome: v still leaks memory for hello world by default
<vagrantc>many of the style commits move inputs from one line per input to a long line or a few long lines of inputs ... makes it much harder to read diffs when inputs change :/
<tex_milan>guix weather qtbase ... it tells me 100% substitues available at ci.guix... and 0% available at bordeax... why it is building it locally and not using the ci.guix substitute? what version it checks against?
<nckx>Again, the default qtbase (‘guix show qtbase’) provided by the exact guix binary you invoked on that command line. Guix packages are ‘part of’ each guix command for practical purposes. There is no package manager binary + external package data ‘repo’ as with other package managers.
<unmatched-paren>[349 19:04:29.060621] [glfw error 65544]: on_gnome_cursor_theme_read: failed with error: [org.freedesktop.DBus.Error.ServiceUnknown] The name org.freedesktop.portal.Desktop was not provided by any .service files
<unmatched-paren>if someone's willing to get a vm with wayland gnome working i'll send over my config
<zimoun>civodul: about offload “guix build --check”, to be to understand: build sends a request to the daemon, the daemon then call “guix offload”. So, IIUC, to offload --check, it is about hook. Right?
<attila_lendvai>what is this new (?) sanity_check.py? it fails for trezor-agent, even though the output seems to work. shall i just delete the phase?
<nckx>I also don't understand the phase (it is extremely Pythony!).
<nckx>Simply deleting it does not sound like a good first step.
<attila_lendvai>i *think* it's something for python *libs*, but this is a "toplevel" app with a wrapper script. but i also don't understand it.
<opalvaults>Which env variable is responsible for .desktop files? It seems as though /etc/profile.d/guix.sh is set correctly, and all of my variables point to where I think .desktop files should be for the guix package manager but are there other places that guix stores .desktop files that needs to be set?
<lilyp>I think we need a better input function for modify-*
<lilyp>Except in the case of renpy, which really needs to go to Guix Past soon
<ngz>Hello. I tried to move to a modular texlive, so I created a manifest file with (specifications->manifest '(... some texlive packages...)). Unfortunately, I'm not able to compile even the simplest LaTeX document. Am I supposed to add `texlive-updmap.cfg' somewhere, somehow?
<lilyp>stupid question, but are you using/have you looked at texlive-union?
<lilyp>IIRC it works like sdl-union, so you can do your own combination (assuming the combination itself makes sense, which idk which ones do)
<ngz>IIUC, texlive-union is deprecated in favor of `texlive-updmap.cfg', hence my question.
<ngz>But, I wouldn't know where to insert texlive-union anyway.
<ngz>Something like (specifications->manifest '(texlive-union (... some texlive packages...))) ?
<ngz>(BTW, what's wrong with Renpy? It hasn't moved to Python3 yet?)
<rekado_>ngz: you don’t use texlive-updmap.cfg in your manifest
<attila_lendvai>"0.0% (0 out of 32) of the missing items are queued" -- and yet i'm building qtbase locally, even though qtbase is not listed as a missing item (using --display-missing). is this an anomaly? or do i have wrong assumptions?
<attila_lendvai>(i have some local commits, but nothing that should affect qtbase)