IRC channel logs
2025-03-18.log
back to list of logs
<civodul>ieure: you need to first do: ,use(guix monad-repl)\ <sneek>civodul, you have 2 messages! <sneek>civodul, rlb says: would it be plausible to mark the 00-repl-server.test inter-protocol test as unresolved for now or XFAIL? <sneek>civodul, rlb says: built main 402e0dfa33f442ad238a0f82a332efa438538840 and ran make check on debian riscv64 (i.e. with the jit enabled), and there were no issues. <aloo_shu>is there a way to search packages online before installing the guix pkg manager, in order to know which version of a given pkg it would fetch? <quezt>my laptop has a bad battery. cannot afford one now. chrony does timesync more flexibly than others I have experienced. <quezt>if I invest in a battery now, guaranteed it will fail in 8 months or so. 50hz current with rampant outages. <aloo_shu>urgh, javascript (lynx is sad), search-as-you-type :( <coyotes4ys>hi, wakyct jA_cOp if you're around, i guix home reconfigure'd with this .scm but no sound in vlc. then i thought i needed to maybe install a pipewire package, but after doing that, same. tried aplay as well and no soundcarfs found <ieure>Okay, what am I missing here? ,run-in-store (computed-file "test" #~(call-with-output-file #$output (lambda (port) (format port "Hello\n")))) <ieure>Gives me "Wrong type to apply" <ieure>This works fine: (call-with-output-file "/tmp/hi" (lambda (port) (format port "Hello\n"))) <ieure>Guile's errors are so unhelpful. <mange>Well, the error is saying that it's attempting to call something. I've run it myself and see the output is saying the whole "computed-file" object is being applied. Presumably run-in-store calls something as a function, but you're not giving it a function. <mange>Have you tried ,build (computed-file "test" #~(call-with-output-file #$output (lambda (port) (format port "Hello\n"))))? <mange>That builds the output itself. I think if you want the derivation itself you can use ,run-in-store (gexp->file "test.txt" (computed-file "test" #~(call-with-output-file #$output (lambda (port) (format port "Hello\n"))))) or something. I'm not super familiar with the REPL interface, but this is what I got by poking it a bit. <ieure>mange, I wanted to see it build. <mange>Great, then ,build should have you covered. ๐ <ieure>Okay, something's still not right here, I know I'm out of my depth. <ieure>I am writing a service for autofs. It doesn't work (expected). <ieure>I'm suspecting that `computed-file' inside the gexp doesn't work how I think. <ieure>(I think it should give me a path to the file it creates) <ieure>Okay, forget that, it makes no sense. <ieure>I replaced (write-master-mount-map #$config) with a constant, so it's just formatting (autofs-configuration-timeout #$config) into the autofs.conf <mange>You're trying to escape an autofs-configuration object inside the gexp, but Guix doesn't know how to compile that object. It doesn't have a gexp compiler defined for it. <ieure>Well, I'm ungexping it. Do I need to define a gexp compiler to ungexp a value? <mange>You're ungexping the name, which means you're trying to write the value which is an autofs-configuration object. Conceptually I find it helpful to think "the gexp is written to disk, and then later run as code". In this case, if you write an autofs-configuration object, it gets re-run in a context that doesn't have that record type loaded, so how should it work? <mange>I would suggest reworking your code so it's only ungexping "simple" values (i.e. take apart the config object at build time, and ungexp the result). <ieure>I conceptually understand that gexps get evaluated by the build daemon, but I don't understand the mechanisms which transport them between processes. I'm using a configuration record, it's a sexp full of consts, I guess I assumed that stuff Just Worked. <ieure>Extracting all the values from the configuration would be annoying, but I did simplify this down so it only writes two files, I guess I can compute their contents in the procedure and only use the gexp to write them into the store. Though that feels very wrong. <ieure>Where would I be able to learn about "gexp compilers?" The manual doesn't mention them and the code I can find isn't clear to me. <mange>In terms of how gexps get transported, you can see. Your earlier computed-file of "test" to write "Hello" to a file has a derivation at /gnu/store/5h53mwk311v3jhw11dw1zl0sc4ya84vv-test.drv, which has a builder at /gnu/store/jxxf2z2npfvn9h1ax64gkj880xgpd3r5-test-builder. This contains your code, with #$output replaced with code to get the output path. <mange>Your record type can't survive this transition because it doesn't have a way to be written that can be read back in (since the record type doesn't exist on the build side). <mange>I see you're using define-configuration. Can you use the serialize-configuration function? It returns a gexp, so I assume the idea is to do something like (define (build-autofs-config config) (serialize-configuration config ?not-sure-what-goes-here?)) <mange>Oh, no, it says to use mixed-text-file. I don't understand how this works at all. <ieure>mange, serialize-configuration is for converting the record into the format the program being configured expects. <ieure>mange, Which is pretty much what I was saying -- all that would happen in the procedure, which would then move the strings into the gexp, which would write them to the store. <mange>Usually I write config files using mixed-text-file, where the function in my file does all the work, and gexp basically just string-appends things and writes them to a file. If I'm reading you're right you think that "feels wrong", but that's how it usually works as far as I can tell. <mange>The daemon side generally has a lot less loaded into the Guile image (you need to explicitly pull in anything you need), so the code there is usually kept as simple as possible. I usually try to keep my logic out of the builders, and instead use gexps to generate the code that I want to run build-side. <ieure>Hmm, okay. I don't think I can use mixed-text-file, but, noted. <mange>I think you could use file-union and mixed-text-file, but you don't have to. Using computed-file can also work if you'd prefer. I think it's best to think of gexps like macros. You don't do things directly, you expand into code to do what you want. mixed-text-file and file-union let you build the code declaratively, and they push you towards "doing it right". computed-file is lower-level, so it's up to you to be mor <ieure>mange, The auto.conf file has to include a path to the master mount map (auto.master) -- is there a way for file-union to do that? <mange>Something like this might do it? (let ((auto.master (mixed-text-file "..." ...))) (file-union `(("/etc/auto.master" ,auto.master) ("/etc/autofs.conf" ,(mixed-text-file ...))))) <ieure>mange, Ah, yeah, that makes sense. <mange>... Where you use auto.master in the mixed-text-file for autofs.conf, obviously. <lechner>Hi, does the 'requirement' field in the Shepherd record only wait for the requirements, or does it also start them? <mange>start-service in modules/shepherd/service.scm calls start-in-parallel on all the requirements before going on to start the service that was asked for. <apteryx>lechner: I think it starts them, and doesn't typically waits on them to be fully started <mange>It looks like starting the dependent services should wait until the "start" procedure for the service has finished running. <mange>I would expect that to be once the service is actually running. <lechner>Hi everyone, I enabled an experimental feature that announces Debbugs changes for the packages guix, guix-patches, and mumi. It's kind of barebones right now but could get better quickly. Please let me know what you think by replying to the email I'm about to write to -devel. <vagrantc>lechner: that sounds potentially very noisy... <vagrantc>guess i will follow-up via email if needed... <lechner>sneek / later tell vagrantc / Hi, like I said it's experimental <rekado>wow, gimp 3 has finally been released <kreijstal>is there a way to install by current git branchname? I want to debug a program using guix to see at which commit it stops building.. <adanska>is anyone having trouble building qemu? <adanska>does anyone know anything about this <untrusem>guix repl: warning: 'rottlog-service-type' is deprecated, use 'log-rotation-service-type' instead <untrusem>I am not using this service in my sytem anywhere <ulfvonbe`>if the build is failing it should be from some other cause <ulfvonbe`>also what you use in your system shouldn't matter at all for what happens in 'guix pull', the process by which guix builds a newer guix happens in the same isolated environment as all guix builds <ulfvonbe`>I don't know anything about an rde channel, sorry <rekado>adanska: there has been a very recent commit to the master branch that affects qemu. <rekado>looks like we have a problem with commit fca507c8f460fbbb7b5bdbae714d930063554b05 <rekado>because the repository has not been archived anywhere. <rekado>even though it's the same hash. Hmm. <adanska>strange, i would have thought the paths would have worked out the same <ulfvonbe`>try renaming the base name (non-hash part) to what it expects, then guix download using file:// <mfg>Does someone know where i can find the actual log files of wlgreet? <rekado>"guix download: error: regular file expected" when I try to use a file:// URL for the directory <rekado>mfg: I'm not using it but the code suggests "/var/log/greetd-*" <mfg>rekado: Those exist, and are non-empty, but look not at all similar to what the bug report contains. They are way less informative just saying that there is an error. Since the bug report stated the logs have been found due to "a kind soul on irc" i asked and hope that someone remembers it :D <mfg>It's also really strange since the exact same config is used on many machines and this is the only one where it doesn't work :/ <mfg>Thanks for looking though :) <Rutherther>h4: what are grafts? it's a feature that replaces runtime dependencies only. Meaning it goes over all the store paths, takes previous path to mesa and replaces it with a new one. It can be used mainly for bugfixes, and is not suitable for something like version changes. But it can be suitable for stuff like adding a new 'driver'(or hos <TaelTydes>hey. is anyone familiar with running audio servers (cl-collider(super-collider) specifically) on foreign distro's? I can see there's home services, but i'd like the song projects to be as portable as possible so just using a manifest currently. <TaelTydes>Autherther: I think it's a pragmatic thing too right, so security fixes can be retroactivlty grafted. <Rutherther>TaelTydes: you cannot really make services with a manifest, the most you could do is build a startup script for it that the user will execute <Rutherther>TaelTydes: yes, that is right, it's the main use case of grafts, security <TaelTydes>Autherther: thanks, I thought that might be the case. I am launching the guix shell from a mkfile right now, maybe I could launch a guix home service from within that pure container if not manually. <futurile>h4: great. I won't labour any difference then :-) <Rutherther>h4: large updates in guix channel are always built by CI on team branch and only then merged to master branch. (Also freedesktop being down is problematic, because it hosts mesa, if that wasn't clear) <h4>Rutherther: Well I could try that I guess, considering I can't even achieve to compile qtbase as is <h4>Rutherther: Guix use a Debian method of pulling from FreeDesktop but original files are available at Mesa3D servers <untrusem>Rutherther, how do you run kmonad service? <Rutherther>h4: I don't think it's about that, guix also has the mesa3d server url in source. I think the more problematic thing is looking through the news, issues, version release notes, ... but here I am stretching a bit and probably podiki will be able to answer in a better way <Rutherther>untrusem: I don't run kmonad service through my config. I will at one point make a service in the home config, but it's not a priority for me as I have a qmk keyboard that I use most of the time <Rutherther>so the only thing I have is, indeed, the udev rules. And the only time I tried kmonad was through a command line, that rule allowed me to run it fine <untrusem>how to I manage my thinkpad batter efficiently in guix <untrusem>thanks for `i` tip in info mode earlies hako <untrusem>it makes searching for things easier in guix <h4>Maybe the ArchLinux page about laptop <untrusem>as I have a fingerprint sensor on my lapton <Rutherther>untrusem: the frpintd service doesn't give any shepherd service. You can try using guix system graph to understand what the services do better, or look through the source <Rutherther>untrusem: so it is expected that you don't see anything in herd <Rutherther>untrusem: the frpintd service doesn't give any shepherd service. You can try using guix system graph to understand what the services do better, or look through the source <Rutherther>untrusem: so it is expected that you don't see anything in herd <rekado>I assumed that we could use guix download to provide the sources for virglrenderer from that mirror. Why does the daemon still attempt to download from the unavailable repository even though a store item with the same hash already exists? <Rutherther>csantosb: on the other hand that instruction by itself is incomplete. You also need to have python installed (in the same profile) as a prerequisite for this to work. <rekado>is it expected that Guix attempts to download virglrenderer sources even though a store item with the same hash (but a different name) already exists? <Rutherther>csantosb: I dont think its implicit for someone who hasnt used guix. If you do something similar with pacman, python is a dependency and pulled as well. Or you can have it in system/home profile and get confused why you cant use cocotb <h4>Giving to Guix for compilation only 80% of processing unit avoided RAM usage topping and OOM and the package compiled but I still don't get why a Mesa change ask for compilation of literally all packages instead of its dependants <h4>And more generally speaking, `make` or any other part of the process should be aware of available RAM to avoid topping it, or, really bad idea but, whitelisting itself from OOM. Idk, like it's dumb that he know he compiles on Linux and 99% of Linuxes run OOM Killer and he don't take that into account <h4>For many software they can just elude the question and tell people to buy better hardware, but here the compilation link cores to RAM, so you get whole kind of situation that could just not sprout <csantosb>Rutherther: from the other side, pulling / installing python is a bit too invasive, and a source of problems ... similarly, cocotb requires optional extra tools, but it is up to the user to decide. <cbaines>civodul, I did make some changes to the mumi exception logging, but for some reason I'm not seeing the backtraces/exceptions in the logs on berlin <cbaines>with a lack of information it's hard to tell what could be wrong, maybe Guile is crashing in display-backtrace <keyboardan>hi. I am pondering in switching to Guix. But I don't like that, with Guix, you are allowed to install a package as a non-root user. Is it possible, with Guix, to make *only* the root user allowed to install/remove packages? <redacted>keyboardan: I'm not sure if that's possible with Guix, but why are you trying to prevent non-root users from installing packages? <redacted>Non-root users can install packages only into their own profile. <csantosb>keyboardan: check 2.1 Binary Installation, it states "Making the โguixโ command available to non-root users". <keyboardan>redacted: "... why?" Because it has been considered an issue, since the start of package manager, to have non-root users install packages on a system. <keyboardan>Anyone with a certain answer to this question, will help me in choosing my next GNU distribution. <ennoausberlin61>Hello. I do not know how the CI builds work, but if I look at the builds for python-pytorch on aarch64-linux, I see them failing for a long time. Is there a way to stop the build attempts until a fix is available or does it burn CPU cycles for nothing if nobody intervenes? <h4>`gtk` segfaulted at 80% CPU resources but succeeded at 75% <ennoausberlin61>keyboardan: The big advantage of Guix is that they will not install packages on the system but into their profile. Or are you worrying about disk space? <cbaines>ennoausberlin61, packages can be marked as supported on specific systems, however in the case of things that could/should work, they usually just build and fail over and over again <efraim>keyboardan: are you aware that users installing packages install them to their own profiles, not to the operating-system profile? <keyboardan>Ennoausberlin, efraim: I am more worried about own security. <keyboardan>My unprivileged account runs all type of software, and I don't want this account to be able to mess with my packages. <keyboardan>The type of software that I run is all Free Software, but I have not checked to see it's code, for security/privacy threats. <ennoausberlin61>keyboardan: All the packages are separated in the store. They do not mess with your packages. And if your users want to software you can not control, they always can compile and run whatever they want in their home directory. <ennoausberlin61>keyboardan: Guix software is "automatically?" checked for CVEs at least it is possible <ennoausberlin61>keyboardan: Have some trust in your users. You can not control everything, but to do changes on OS level in Guix you need root rights <keyboardan>I prefer *root-control only* on my package installation/removal. I am not in Free Software for faith, instead of analysis. So, trust is faith. Not the goal, here. <keyboardan>I don't feel like loosing *root-control only* on my package instalation/removal. <keyboardan>And I won't. Is Guix incompatible with this requirement? <Rutherther>csantosb: as far as I remember to properly use cocotb, you need to run python scripts by executing python directly (non wrapped executables), so that way it is impossible to use without the search paths. But I might be misremembering <ennoausberlin61>keyboardan: What let you feel uneasy? The user can not change your systems packages. They have their own "space" which does not interfere with other users. I have users that use completely incompatible versions of some software independently. It is like an local environment and isolated from the rest <keyboardan>as a side-note: everyone was cool with using Instagram and Twitter/X until musk political standpoints. I was not cool with bigtech. Same applies here, every Guix user is cool with unprivileged control over package instalation/removal, until something similar to musk situtation, happens in Free Software. <ennoausberlin61>keyboardan: Can you elaborate on that? Guix is a libre distribution or package manager. Free software only <keyboardan>ennoausberlin: the issue is not with other users, but with my own unprivileged account. My program's execution, and my security. <keyboardan>It is not other users on my system, the issue. it is more about security that used to work, being discarded by Guix. <keyboardan>Namely, *root-only package installation/removal*. <efraim>looks like debian only uses qnnpack on x86_64 <redacted>keyboardan: Prevening users from installing packages to their home directory is not a security measure. <ennoausberlin61>keyboardan: But you decide which software you install. I am not a native speaker, so there might be a problem on my side. I use Guix because I have full control over the packages and can see at any point in time, which software is present on the system to easily check if the system is vulnerable to some new exploits and due to reproducibilty <redacted>Users can still download and run binaries from the Internet. <ennoausberlin61>Good luck, but Gentoo will not help you with this security "issues" any better <keyboardan>I know. I don't want to start running a program that I did not install, because of some package vulnerabitity that gives a shell on my current user. <keyboardan>Or some program that is different from what I have installed. <ennoausberlin61>You can not run a program, that you did not install, except with binaries you installed on the system level and even there you have full control <redacted>Preventing non-root users from installing packages won't protect your PATH variable either. <redacted>Guix does NOT let non-root users modify the environment of OTHER users. In order to trick you into running a different binary than the one you intend, your user account has to be already compromised. <keyboardan>I know my PATH is vulnerable. That is why it is the only point that I have to check, with my system :-) . <Rutherther>keyboardan: there never was root only installation possibility. The only limitation comes from package managers not being able to handle non fhs filesystem and only root can write to directories like /bin. Users can always install sw with other means. For example guix provides pack functionality, giving you relocatable sw executable at any Linux machine of the same arch <redacted>keyboardan: Then it's not clear what you're confused about. <keyboardan>redacted: the possibility that I am tackling, is with my own account being compromised. <hapster>anyone here using guix on a foreign distro and able to help with a major pain regarding getting guix to work in the first place? <hapster>I am on openSUSE Tumbleweed and am having an awful time getting `guix pull` to run successfully <untrusem>I think necto and futurile are of foreign distro <hapster>nscd is deprecated in rolling release and more recent distros -- debian still has it for example, but openSUSE Tumbleweed, Arch Linux and Fedora don't <TaelTydes>hapster: I'm having issues with guix overwriting my .profile myself on alpine but I've ran guix home before. What's happening when you try pull? <hapster>and when I try to run guix pull, the hostnames of the substitute servers can't be found which is why `guix pull` fails saying that ai_soctype is not supported <TaelTydes>hapster: have you tried replacing the channels file manually? <hapster>now, I have a machine where guix pull works, and have used `guix archive --export -r nsncd > nscnd.nar` (source) and `guix archive --import < nsncd.car` (target) to get this package to the store. Now I have a systemd job that runs nsncd, but it still doesn't work, saying "ERRO error handling request, err: Error: getservbyname_r failed with code 2, request_type: GETSERVBYNAME, thread: worker_$N" <hapster>TaelTydes, I don't have any channel file in place, I fail during the initial guix pull after following the binary installation guide from the manual <TaelTydes>i'm unsure if I remember that happening myself, worth a try. <hapster>before I was able to just install nsncd from some shady opensuse tumbleweed repo, but now there is a mismatch between the used gcc version of the package and the system, so that doesn't work, and I am starting to pull my hair a bit right now <Rutherther>hapster: does the nscnd log contain anything worth noting? Also, are you sure the socket created by the service is accessible by the guix build user? <hapster>Rutherther, where does nsncd log to? <Rutherther>hapster: I dont know, I presumed to stdout of the service, being accessible by journalctl <hapster>Regarding accessibility, it has the same owners as the /var/run/nscd/socket and the same permisisons than on the other opensuse system which has the "original" nscd installed <hapster>ah yes, when I try to run `guix pull`, I receive the error message above, once for each worker: "ERRO error handling request, err: Error: getservbyname_r failed with code 2, request_type: GETSERVBYNAME, thread: worker_$N" <Rutherther>hapster: so that is from the service log, not from guix pull log? <hapster>guix pull log says "substitute: Liste der Substitute von โhttps://bordeaux.guix.gnu.orgโ wird aktualisiert โฆ 0.0%guix substitute: Warnung: bordeaux.guix.gnu.org: Rechnernamen nicht gefunden: ยปServnameยซ wird fรผr ยปai_soctypeยซ nicht unterstรผtzt" <hapster>(host not found, servname not supported for ai_soctype) <Rutherther>hapster: you are saying the perms are the same without noting if the build user has access - its important then the users are also in the same groups if there is perms missing for others <bjoli>I just found a flatpak home service that looks handy. Are there any ideological things stopping it from getting merged into guix? (If the author agrees, of course) <Rutherther>Okay, since the log is from the service, the socket is accessible for sure then <hapster>Rutherther, I am not sure how to check this <untrusem>how to setup python environment in guix? <untrusem>like installing python virtualenv and pip <Rutherther>hapster: btw have you tried hacking around this by adding the substitute ips to /etc/hosts? Not sure if the nsncd is needed just for substitutes or everything guix builds, but maybe worth trying. I really cant say what is wrong with the nsncd. The only other thing I can say is to try to match the srartup arguments and config used as on the other system <Rutherther>untrusem all those are available under the python package (note that they are called with suffix 3, and venv might not be an executable, but is executed by "python -m") <hapster>Rutherther, Adding said lines to the host file doesn't change anything unfortunately <hapster>I found out the IPs using `dig`, I hope that's the way to go ;-) <Rutherther>hapster: in this case it would probably be better to restart the guix daemon service, I dont think logging out and in can have an effect on this <hapster>well, I guess that's my nsncd adventure for today. Thanks for your help! <Rutherther>hapster: okay, I can try going through the source in few hours to see if I can find cause of the error you're getting. Until then I am out of ideas <rekado>(FYI python 3.11 will be the default once the python-team branch is merged.) <hapster>Rutherther, that would be lovely. If you don't mind, I'm grateful for a ping in case you find something <Rutherther>untrusem: if you arent planning on using guix python packages, then guix has 3.12 as well, named python-next <apteryx>where does the pk output goes in marionette-eval, for system tests? <apteryx>untrusem: I'd check what the service file runs exactly, and experiment "by hand" <apteryx>or if it has a system test, run the associated vm and troubleshoot in it <Rutherther>apteryx: what is herd saying when you start it and is there something in the log+ <untrusem>herd: error: failed to start service tlp <apteryx>Rutherther: ah, the error is earlier to my pk. it gets reported way before the rest of the test output for some reason <apteryx>with the imports resolved it works, but pk output is still nowhere to be seen <Rutherther>untrusem: that is strange. In that case I would also agree with aptertyx to run it by hand <civodul>apteryx: hey! pk output probably goes to /dev/console, but we donโt know for sure :-) <civodul>ACTION found git://anongit.freedesktop.org/virglrenderer which should help us fix the virglrenderer fallout on โmasterโ <apteryx>oh, I've missed the fallout, thanks for the heads-up <civodul>itโs annoying because qemu depends on it <Rutherther>untrusem: yes, but exactly what is ran by the service <apteryx>and /dev/console should be merged into /var/log/messages? <civodul>no, /dev/console should appear in the โserialโ output of qemu <Rutherther>untrusem: your current invocation doesn't contain the path to the configuration file used by guix's tlp service <untrusem>> untrusem: your current invocation doesn't contain the path to the configuration file used by guix's tlp service <apteryx>civodul: it's funny, I have the checkout on my machine <apteryx>I could probably offload to berlin to have it fixed presto, but will investigate for a proper way first <apteryx>ah, they are migrating. maybe my presto hack is the right thing to do then <civodul>apteryx: yeah, i actually cloned from anongit, checked out 1.1.0, but then i get a different hash <civodul>so yes, maybe you can do it as you suggest <apteryx>uh uh, my key no longer is authorized on berlin. hm. <apteryx>(I was trying: ./pre-inst-env guix copy --to=berlin /gnu/store/vqzys49w14vs1klpkr7pz35jlfrhlksj-virglrenderer-1.1.0-checkout) <apteryx>civodul: ah, my key never was authorized on berlin directly, it is for select non-x86 build nodes such as overdrive <apteryx>overdrive1.guix.gnu.org seems unreachable <civodul>apteryx: or you can copy the checkout and then do an add-to-store RPC to include it (no need to be authorized in this case) <civodul>guile -c '(use-modules (guix)) (define s (open-connection)) (pk (add-to-store s "virglrenderer-1.1.0-checkout" #t "sha256" "virglrenderer-1.1.0-checkout")) <Trugschluss>Anyone here ever had an llm running on guix system? Pretty new to it and wondering if anyone could share some advice if there are some things i should keep in mind regarding guix' peculiarity <apteryx>civodul: seems to have worked, we now have /gnu/store/gcvjhnf1j7n1ia2fccishflg3g7xaqp1-virglrenderer-1.1.0-checkout <apteryx>not sure why the hash is different, hm. <peterpolidoro>atril: symbol lookup error: /home/peter/.guix-extra-profiles/desktop/desktop/lib/gio/modules/libdconfsettings.so: undefined symbol: g_once_init_enter_pointer <peterpolidoro>I have started getting this error when I try to run several programs <Rutherther>peterpolidoro: guix extra profiles? then my guess is that this gio module is version incompatible between the various profiles. Unfortunately this isn't easy to fix now other than syncing the versions of the profiles <Rutherther>yes, updating all profiles at the same time is fine as long as you don't have pinned packages <Rutherther>lechner: is it really good idea to let it 'spam' here? wouldn't a separate channel make sense? also, why doesn't it filter out guix issues? or at least say which project the issues are from? and lastly, could it say what exactly 'changed'? imo it's much better if you saw stuff like 'created', 'closed', 'new message' etc., and maybe at least the name of the issue, like this I have to open something else to check if I am even interested in that (and my... <Rutherther>... guess is that not many people know issues by id) <apteryx>Rutherther, lechner I'd welcome status updates on bugs in the channel, at least perhaps a subset (new issue, closed, etc.) <apteryx>having the title or a shortened version of it would be nice yes to give some context <Rutherther>btw I sent email to lechner (it's on the guix devel list) with my previous message points, because they said they might not be reachable at least in the #emacs channel <apteryx>civodul: nevermind, it was a rsync classic fail of having a nested directory in the target due to forgetting a trailing '/' <apteryx>/gnu/store/645h7i0rsvg40kxr2mvqwkc9if6j0dr5-virglrenderer-1.1.0 built successfully on berlin, so problem should be solved. thanks for the add-to-store snippet <Rutherther>but I noticed I might have been too fast to conclude it doesn't filter projects, I just saw the issue number and that I can't load it in mumi interface, but that was just because it wasn't picked up by it yet, so one of my points is mistaken <apteryx>got uefi firmware working for libvirt out of the box <apteryx>guix system build doesn't seem to allow --with-source and friends <Rutherther>PotentialUser-45: how is it preventing you from installing qemu? <redacted>the build is failing, and it's a dependency <Rutherther>sneek, later tell hapster: so the error 2 on getservbyname_r means "no more records". In other words, means the _service_ name is not known, service is stuff like https, to get its port. I now realize the issue after looking this up - your substitute doesn't have a protocol specified. You have just bordeaux.guix.gnu.org, that is causing the issue. You seem to be having the same substitute twice, but once without protocol. But yeah, the error is quite... <lechner>Rutherther / Hi, are bugs really spam? <lechner>apteryx / the closed/amended or whatever details are in the works. this is experimental <lechner>apteryx / peanuts currently provides the details but I can tell peanuts not to listen to debbugs and save a line <Rutherther>lechner: in this channel imo yes, but that's a matter of perspective, I would prefer something like #guix-bug channel (that I would even like to join, I just don't like them here in this channel) <apteryx>right, I saw that it was doing that it missed a couple bug#xxxx, it must have been restarting or someth6g <apteryx>ACTION is confused about what the firmware bit does in osinfo-db <lechner>Rutherther / no one here likes bugs. no one works on them. you call them spam. that's the culture i'd like to change <apteryx>I thought it would make an OS auto-magically pick UEFI if it was advertised as supporting it <Rutherther>yeah, I also said that there is no info about the bug when peanuts wasn't replying. And I messaged that the issues are not filtered since I couldn't open it on mumi, but that was also just because it wasn't loaded yet. So sorry about that. <lechner>Rutherther / i currently only announce changes in guix, guix-patches, and mumi. Do you see any other Debbugs reports here? <apteryx>Rutherther: I'll turn the sync rate up from 5 min to 1 min perhaps tomorrow, it'll improve Mumi's reactiveness to new issues. <lechner>also, just as a general remark I'm trying to helpful. my hope is to propel Guix, not to impede it <Rutherther>lechner: I don't call _bugs_ spam. I call anything that is not on topic and is commonly sent spam. I think debbugs issue updates is not on topic of this channel, that's why I call it spam. Not because it's bugs. <lechner>apteryx / i think one minute is too fast <Rutherther>lechner: no, I don't, as I said, it was my error that I thought it's not a guix issue <apteryx>with the new shepherd timers api it'll be able to block until it's done (and not run multiple sync in parallel) <lechner>okay, please let me know but my runs often take two minutes <lechner>i also rsync and would be curious about your experience. please send me an email, however, as i'm not always here <apteryx>will try to remember, otherwise will let you know here at some point <lechner>cbaines / Hi, are we getting together today? <cbaines>lechner, I'm still happy to meet up in just over an hour, I'm only free for a short period though <lechner>Rutherther / bugs are in the /topic of this channel <Rutherther>lechner: I think that is stretching what it means. The topic is just kept as short as possible. So many interpretations arise. This channel is for discussion, not for automated updates imo. <Rutherther>lechner: I think that is stretching what it means. The topic is just kept as short as possible. So many interpretations arise. This channel is for discussion, not for automated updates imo. <lechner>cbaines / we must be on different daylight savings times. it's 9 AM Pacific <lechner>Rutherther / the updates are not automatic. they are triggered mostly by meaningful human interaction with the debbugs database <redacted>Rutherther probably meant *automated* then <cbaines>lechner, ah sorry, seems like the US and EU times I mentioned in the email are an hour out <lechner>it's okay. i've been surprised by it more than once. it's just this week in the spring, i think, and no gap in the fall <Rutherther>checking. I even wrote automated, not automatic. Meaning the updates are sent here without any human explicitly sending them here. Not that they wouldn't be sent after an interaction human made. The difference is, that, it's very well possible no human here wants to talk about them here currently, so they are just getting in the way of other discussion. Moreover, at least my client doesn't allow some kind of filters like for example do, where one can... <Rutherther>... just filter out lists / keywords etc. Here I just see everything, so I have to acknowledge them and skip them in my head. I am very happy to check what is going on on debbugs periodically, the same way I acknowledge what is going on at the lists, but I don't like the current realization by sending it to this channel <Rutherther>s/allow some kind of filters like for example do/allow some kind of filters like for example emails do <lechner>Rutherther / wouldn't it be helpful to know about active bugs when users come here? <lechner>in any event, i realize that these announcements are new and that folks are skeptical. at this point, i'm competing with codeberg. they have hooks, too, and you may get them here <lechner>another point of consolation that Guix may not use Debbugs much longer, making these announcements obsolete in a month or so <Rutherther>lechner: I like that you're trying to compete with codeberg. Why I am saying this all is that I am not sure if this is the way to do it. If the messages are going to be unwarranted by users, debbugs can 'lose points', not gain them. I am just saying my personal impression to those messages, it's very well possible I will be of few that see it that way, maybe someone else can add how they see it themselves. <redacted>IMO IRC is more like a makerspace than a help hotline, and people get them confused. While you can get help at a makerspace, it's disrespectful to assume your problems are always a priority there. <redacted>Automating these announcements necessarily disregards what everyone is doing at the time and assumes "well of course you want to hear about this!" <lechner>redacted / how many bugs have you closed in the past month, please? <ieure>lechner, Don't like this argument at all. <lechner>i thought all agree that they should be closed <dazage>redacted: I think that's a good way of putting it <lechner>and what are people working on, if not bugs? <ieure>lechner, Is your argument that unless you close bugs, your opinion on the mentioning of them is invalid? That seems to be what you're saying. <lechner>no, i was curious how many bugs redacted was able to close without the Debbugs announcements <ieure>Not sure about the last month, but I've closed ~60 guix-patches bugs since I got my commit bit in January. <lechner>that's great work! were you particularly enthusiastic because you became a committer or is that pace sustainable <Rutherther>lechner: I would expect most maintainers be subscribed to the guix-patches and bug-guix mailing lists and/or checking the debbugs tickets directly when they can, so I am really unsure announcing it here can change something about that <redacted>And, even if it *did* increase the number of bugs fixed, you're still assuming that closing bugs is the only important consideration. <redacted>Interrupting people with bugs might get more bugs fixed. IMO, it's still rude and inappropriate for a community of hobbyists. <ieure>lechner, A handful were mine, 2-3, most weren't. Definitely some early enthusiasm, but I've been sustaining it so far. <lechner>ieure / you should get a medal. is anyone keeping stats? I may be able to <ieure>I don't think so, I was curious so ran `git log' to find whatever I'd signed off on. <ieure>Since I've been focusing on stuff I care about (emacs), the backlog is greatly reduced, so the work going forward is reduced. <rekado>lechner: "what are people working on, if not bugs?" -- things that would be reported as bugs if we didn't work on them <ieure>lechner, I also found several patches that'd been applied, but the bug not closed, so I closed those. <rekado>for example, I spend most of my days maintaining a huge collection of packages that I have no personal interest in. <lechner>ieure / either way, i think one a day is a great number. <rekado>FWIW debbugs announcements won't help me get any more work done. <ieure>lechner, Thanks. It feels like I'm making a difference, which feels good. <rekado>notifications on any system ought to be opt-in. <rekado>bot messages on this channel make it less likely that I can assist humans on this channel. <lechner>as a group, i think we ought to reward people who close bugs. bugs express the pain of real users. they also make guix appear unprofessional and, in some case, unusable. these are users who depend on committers to listen to them <rekado>outdated packages also make guix appear "unprofessional" and "ususable" <redacted>This entire line of argument is disingenuous and manipulative. <lechner>we can keep track of those also. as in my emails, my argument isn't about anyone's contribution in particular. there should be a comfy place for everyone in Guix, but as a group we have to get stuff done <ieure>I will say that I find the bug announcements valuable, but would also like to see them in a dedicated channel. <lechner>rekado / would anyone object, for example, if we tracked, like repology, how much Guix lags behind our upstreams? <rekado>by the time my volunteer contributions are reduced to metrics I'll gladly leave the field to the bots. <lechner>i think you just resist being measured <lechner>okay, i'll be happy to take more flak here after cbaines is done <cbaines>no, and I'm still finishing dinner at the moment, so it's a little difficult for me <lechner>well, i'm not sure there anybody here so maybe we should postpone <lechner>cbaines / okay, i took a look at your stuff and really like it. it's a lot like what I did at another project and seems to work even better <lechner>sorry baby got locked in the bathroom <lechner>no sweat, still have a hole in the wall from the last one <lechner>cbaines / i am not sure how you can do all this with HTTP (and without messaging) but it looks great! <cbaines>unfortunately I think there are still a few key bugs to fix in the build coordinator, but I'm glad we're back to good substitute availability levels for the master branch <lechner>cbaines / Debbugs is painfully out of style, but I could set you up there <cbaines>although I didn't actually notice that mumi is there <lechner>after all the stakeholders agreed that it was a good idea <lechner>any place is fine, really, but you should have something so we can work on it together <cbaines>indeed, and this isn't something limited to the build coordinator <lechner>you mean also other components of your system? <cbaines>yeah, and while I'm still unsure about using Codeberg or that style of forge for Guix, it does seem that the forge approach of providing issue tracking and patch tracking for each Git repository would be helpful <cbaines>as along with the build coordinator, there's also the data-service, nar-herder, qa-frontpage, bffe, guile-knots, ... <cbaines>all of which don't have a great story for issue and patch tracking <lechner>cbaines / have you given any thought to a name for your project overall? <cbaines>I struggle with naming, I got a bit creative with the nar-herder and guile-knots, but I'm not sure there's really a need for a creative name <lechner>"build coordinator" very hard to search for online <cbaines>I think squatting the QA term is fine and associating things with that, e.g. qa-frontpage <old>would be nice to have languagetool package! <cbaines>unfortunately I'm running out of time today, but I'll try to arrange another QA related meeting in a few weeks <h4>What means quality insurance here? <lechner>or rather, whether patches submitted to Debbugs build properly when applied <h4>lechner: So like a required rate of build success across time? <h4>Bit like high availability who seek 99,99+% availability <h4>That we could call availability insurance <lechner>h4 / my naming request to cbaines was about being creative. I agree with you that QA may not be the right name right now but it may be at some point in the future <h4>lechner: Yeah maybe, it boils down to hermetic language. Saying things that are true, but ungraspable without being into the circle <h4>I rather like things that could be understood by anybody in the street, but I guess that too much context and simplification would create dizyness aswell lol <lechner>h4 / thank you for your input! you are a valued and important member of the team <lechner>I'm happy to take more reactions to the bug announcements for another 100 minutes, then i have to go <ngz>lechner: Closed (and maybe opened) bugs will be announced on this chan, right? <h4>(if it's unironic ๐, maybe a more bland message would transmit the feeling better lol) <ieure>lechner, My feedback is that I like the idea, but would like it in a different channel, perhaps #guix-bugs. <ieure>If one doesn't like the noise in #guix, one can /ignore it. But, since it triggers a lot of messages from peanuts, that won't stop all the noise. And ignoring peanuts means you'll miss *everything* from it. I think folks should be able to choose one or the other. <lechner>ngz / right now, all changes to bugs are announced. that's due to the antique way bug data is collected and shared (in modified mbox files). most vexingly, it also announces the archiving of bugs, which makes no sense. I'm working on more meaningful messages when bugs are opened, closed or amended <lechner>ieure / again, i'm not sure i agree with the characterization of bugs as noise. i believe it reflects a dismissive attitude to what often are real problems in Guix that should be fixed by the first committer that sees them, especially when there is a patch <ieure>lechner, I am not dismissing anything. Whether it's noise or not is subjective. If you're someone able to do something about the mentioned bug, it's valuable; if you're a new user looking for help (as many, many people in here are and do), trying to find it through the automated messages, it's noise. <ieure>That is why it should be a user choice whether to see it or not. <ieure>I think having them in a separate channel is the simplest way to do that. Another option would be to let people opt in (to everything, or some subset of bugs) and receive DMs. <jA_cOp>I've only been here for a few weeks so far, but I like the bot! I concur that the bot should probably include the URL and then be ignored by the other bot, for more compact messages. And if the Codeberg GCD goes through, I hope the bot will be modified to work with Codeberg - it's a good idea regardless of the upstream source IMO! <jA_cOp>lechner: sorry, what do you mean by position in the project? I'm just a new Guix user. I haven't found peanuts to be annoying, except maybe the message it sends every time you mention it. I've seen a different approach to that which might be less intrusive. But maybe I haven't been around long enough to notice <jA_cOp>^ for something like this, I assume the idea is to direct people to information about the bot - an approach that might work better is to have a command like !peanuts or w/e that prints this message, which regular IRC members can invoke whenever someone has a question about the bot <lechner>jA_cOp / people used to talk to it and asks around who this person is. please call it pe*nuts or so <jA_cOp>i.e. a human can determine whether or not it's an appropriate time to post that message <Rutherther>lechner: I very much like both the bots, but would like to see debbugs in a different channel <lechner>Rutherther / thank you, your objection was noted and won't be ignored <Rutherther>lechner: I very much like both the bots, but would like to see debbugs in a different channel <Rutherther>the peanuts bot is super useful especially when I am on my phone and someone sends a link, I can just click on it and see it right away <lechner>jA_cOp / is !pe*nuts with the exclamation mark standard? <jA_cOp>lechner: I've seen various names for the command itself, but the exclamation mark prefix is a common convention for bot commands on IRC <Rutherther>the peanuts bot is super useful especially when I am on my phone and someone sends a link, I can just click on it and see it right away <jA_cOp>something more generic and boring might be !botinfo <ieure>Agree that the ! prefix for bot commands is established and decades old (I was using that in the 1990s on EFNet). You generally don't mention the bot at all, just !do-something and the bot (whatever its nick) would. <ieure>The bot in #emacs uses , instead, because Lisp. <jA_cOp>sometimes there are "help bots" which have various pre-configured snippets for frequently asked questions - like if someone asked "why is guix pull slow? is my guix broken?" another user might run !slowpull and a bot would link to somewhere with a (presumably useful) "canned response" <jA_cOp>ideally followed up with a friendly human touch since a canned response can seem a bit cold, but that's an aside :) <Rutherther>btw if I would like to see a new feature in debbugs, where is a good place to discuss it / find if there has been discussion about it? <Rutherther>btw if I would like to see a new feature in debbugs, where is a good place to discuss it / find if there has been discussion about it? <ieure>Rutherther, Something weird with your client? It's posted dupe messages a few times today. <Rutherther>ieure: yeah I know, but I have no idea how to debug it, sorry for that <vagrantc>lechner: definitely of the opinion that the debbugs bot should probably be on a separate channel and include the full link and ideally summary of the type of change, rather than relying on yet another bot to post the link <sneek>vagrantc, you have 1 message! <sneek>vagrantc, lechner says: / Hi, like I said it's experimental <vagrantc>being able to opt-in to the messages is essential to being able to focus... <lechner>Rutherther / i'm happy to implement your suggestions in my clone at patchwise.org. From my experience the GNU folks won't change anything except bugs. they modify a live system. as far as i know, i'm the only one with a Git repo of the deployed source tree. <vagrantc>having bots respond when expressly asked for also seems better ettiquette, in my opinion <lechner>they are being asked. by countless users trying to be heard in this forum of experts <ieure>"as far as i know, i'm the only one with a Git repo of the deployed source tree." -- well, that's terrifying <lechner>i know. it's been like that for fifteen years <jA_cOp>a majority of the regular readers/posters in the channel know it's a bot, and can clarify that to new users who are confused. It's really just about trusting that a human knows when it's appropriate to clarify it. But I don't think it's necessarily a big deal that it auto-responds to being mentioned, either :) <Franciman>lechner: a super slow codeberg is still better than a uber fast github <lechner>i am not complaining as a matter of principle. i'm trying to show jA_cOp that I implemented !peanuts <Rutherther>lechner: that sucks. In case guix doesn't switch to codeberg, is switching debbugs instances on the table? And btw your instance of debbugs is just like an e-mail subscribed to the bug and patches lists, and thanks to that it can receive the issues? <lechner>jA_cOp / in my excitement i forgot to credit you, but i will soon revert and give you authorship in Git as well as a copyright entry if you tell me your name <jA_cOp>lechner: nice! But I hope you are joking, it's a trivial suggestion. Thanks for your work on improving Guix and the IRC experience <3 <lechner>Rutherther / patchwise.org is currently a Mumi mated to Public Inbox plus a bunch of extra stuff like my bots <Rutherther>lechner: oh so there is like an mbox file hosted somewhere and it's fetched periodically? <lechner>jA_cOp / actually, as someone who has fixed many hundreds of bugs I would like to recognize the value of your contribution. as the channel log shows, your idea was not trivial at all. you can also PM your name <jA_cOp>lechner: thank you, and I think you're right in the general case. If you want to, you could credit me with my nick name. But I don't mind if it goes unmentioned. Thank you for asking, though! <lechner>Unfortunately, I cannot use your nick due to limitations in US copyright law <[>what limitations in US copyright law? <lechner>is that the unmatched parenthesis we know? <[>I'm not unmatched-paren <lechner>as far as I know, US copyright attaches only to natural persons and can be assigned from there <jA_cOp>lechner: I do believe that the copyright to the code is yours, since you wrote it, and I didn't suggest any code. And while IANAL, I don't think the idea itself is eligible for copyright! :P But more seriously, would that mean you don't accept pseudonymous code contributions to your bot? Because I think I read that Guix does, and I do like that <ieure>Falsehoods US Copyright Law Believes About Names <[>US copyright law does not require a copyright notice. There's no reason you couldn't credit jA_cOp's contribution with their nick. (I'm also not a lawyer) <jA_cOp>lechner: as for contributor #3, maybe I'll think of something to contribute and you might consider a pull request in the future? Getting contributions does feel good ^^ <lechner>okay, i'm not trying to force anyone <lechner>jA_cOp / in that event, thank you for the idea! <jA_cOp>I don't have an email setup yet, there's some extra steps for protonmail users. But I will set it up if the Codeberg GCD is rejected or significantly postponed. But I like to read about Guix development via the web interface in the interim, so the bot is a nice addition (regardless of which channel it ends up in) <lechner>ACTION wonders how a pseudonym can enforce a GPLv3 license <Rutherther>jA_cOp: btw hydroxide is packaged in guix (smtp/imap bridge to protonmail) <jA_cOp>Rutherther: yup, it's on my to-do list! I've had positive experiences with hydroxide in the past <lechner>jA_cOp / with some luck we can now chat about peanuts without interruption <jA_cOp>perfect :) I for one will try to help people who are confused by peanuts responses when I see it. Let me try it <kreijstal>ulfvonbe: what about an specific commit, also --with-branch seems like a modifier, instead of defining a package by itself..? is there a way to do it without modifier? (the conversation was about a way to install by git branch) <jA_cOp>lechner: should the !peanuts invocation have worked? <lechner>this has to do with 'bow' in irregex <mightysands>When the Hurd website says it can't handle X window systems with coreboot because coreboot doesn't use VESA drivers, and Hurd currently lacks Direct Rendering management, is this to say that Debian/Hurd also can't work with coreboot ? <mightysands>I'm asking here because what I'm really curious about is if anyone's heard news recently on how Hurd is going, and ik guix and Hurd are pretty close <mightysands>Wondering how far away a GNU Boot/Guix/Hurd computer might be <mightysands>(with internet, sound card functionality and working video) <kreijstal>I think one way to answer is to instal hurd and try :D <ieure>mightysands, My understanding is that Hurd is not daily-driveable. <mightysands>Someone got Hurd running on an X60, but it doesn't have working sound or internet I don't think. For some reason Debian/Hurd is a lot further along than Guix/Hurd <mightysands>(ik it began in the 90's (debian/hurd) and Guix is more recent, but the reason it surprises me is because I would've thought that most incompatabilities would've been Hurd based, and since ironed out by now, not debian based. i.e: The low level parts work, so one can just compile everything and voila) <vagrantc>lechner: they are not being asked by me, and i did not consent to a firehose of information coming in here ... your response seems to just ignore the substance of what i have said ... <vagrantc>lechner: i am describing what would make them seem more useful that frustrating and your response is not inspiring confidence <jA_cOp>Does the debbugs bot check for updates every so-and-so many minutes? If so, it could also batch updates into one message, instead of posting multiple messages simultaneously <vagrantc>it seems like bad form having bots talking at each other and responding to everything said in the chat <vagrantc>as opposed to targeted hey !bot could you get me some useful information please <vagrantc>lechner: i know you see value in it, and i trust your intention is good ... and i can even see potential value in what you're doing ... but please err on the side of consent <lechner>vagrantc / by having the bot post elsewhere, you are effectively suggesting to turn it off. you called it a firehose <lechner>jA_cOp / that will work now but soon messages will diverge depending on whether the bug was opened, closed, or amended <vagrantc>lechner: i am fine to subscription based firehoses ... i can join them when that is what i am looking for <vagrantc>lechner: another approach to a firehose problem, is to reduce the number of things it responds to down to a level where you do not have people complaining <lechner>vagrantc / i am very keen of listening to make things useful (and your line-saving suggestion was just implemented) but most of what I read here are knee-jerk reactions <vagrantc>lechner: i do not want peants to tell me where to report issues about peanuts or have to workaround it byspelling the name weirdly <jA_cOp>lechner: maybe formatted like so? "OPENED: Bug#xxx, Bug#xxx. CLOSED: Bug#xxx. CHANGED: Bug#xxx, Bug#xxx, Bug#xxx" when there have been multiple changes in the last interval. But it's tough to integrate subject lines with this format, for sure. <ngz>Canโt any decent IRC client be tweaked to hide such bug notifications anyway? <vagrantc>i would rather solve social problems socially that putting on an ineffective technical solution <ieure>ngz, As I mentioned earlier, debbugs causes peanuts to print messages so ignoring debbugs doesn't ignore the messages from peanuts. And if you ignore peanuts, you lose both the automated notifs and the ones from humans mentioning bugs. <vagrantc>lechner: i am glad you are keen, but this particular interaction seemed quite off-putting <vagrantc>12:14 < vagrantc> having bots respond when expressly asked for also seems better ettiquette, in my opinion <vagrantc>12:15 < lechner> they are being asked. by countless users trying to be heard in this forum of experts <ieure>lechner, The fact that you're characterizing what I think has been thoughtful discussion and helpful suggestions as "knee-jerk reactions" is tremendously offputting. <ieure>lechner, It gives the impression that you will continue with this project no matter how the people in this channel feel. This could be a mistaken impression, but it's the one I'm getting. <jA_cOp>Multiple people have already said they would join a separate channel with this, and I would too. But I also wouldn't mind if it was in this channel, with some improvements to compact messaging as has been discussed. Maybe use a separate channel while working out the kinks? I might be able to help on the development side <ieure>I would also join a separate channel for them. I would find value in that. <vagrantc>ooops. too much sunshine. would you believe it. <ngz>ieure: hide messages from debbugs, but store the referenced bug anyway, then ignore the next message from peanuts pointing to that bug ;) <vagrantc>or how about peanuts just ignores debbugs? wouldn't that be a useful solution? <rekado>like ieure and vagrantc I'm not too happy about the way criticism ... ugh. Never mind. <ngz>vagrantc: Great idea. Not sure it qualifies as a social solution, tho :) <lechner>i like to eat peanuts at the ball game <lechner>for the debbugs thing we have to wait <vagrantc>ngz: that is a technical solution to a technical problem. i do not think bots ignoring each other is a social problem. :) <vagrantc>i do have a couple bugs i need to file... <mra>Hm, still no updates on 41602. bummer <mra>I meant to follow up but I've been swamped with writing phd applications <vagrantc>lechner: that is looking much better, thanks! <jA_cOp>lechner: ah neat, is that ii? (the IRC client) <mra>actually, i would appreciate if anyone has time to test the change? guix publish fails on my machine both before and after the change, so it would be nice to have someone for whom it works check that the changes are good <vagrantc>lechner: still unsure if all statuses on all bugs needs reporting... but i guess that is why it is an experiment <lechner>vagrantc / yes, refining that requires parsing ian jackson's file format from 1994. i have a draft but would rather take over the gnu instance <lechner>vagrantc / i have to pick up my son from school in five minutes but please consider in your criticism that my goal is to lighten the cognitive load of the mailing list. as in debian, i'd like substantive technical discussions that do not affect larrge portions of the project to take place in bug reports. they are focused and easily found, neither of which is true for the list <jA_cOp>if guix-patches is like other distros, I imagine simple "updated X to version Y" patches have generally poor signal-to-noise ratio. Not sure how easy it would be to detect such patches <jA_cOp>I mean like - classifying patches as a "simple update" for the purpose of filtering it out, not sending it to IRC <jA_cOp>but who knows if it's even really a problem, we'll see over time I'm sure :) and for those who really don't like, they can now /ignore debbugs <jA_cOp>yeah, and occassionally substantive discussions do happen on such patches <jA_cOp>speaking from experience in other distros, but maybe true for Guix too <lechner>it's hard too, though, because the patchsets interleave. that's all stuff i'd like to address in the future <jA_cOp>Void Linux and NixOS come to mind, they use Github <sneek>Welcome back hapster, you have 1 message! <sneek>hapster, Rutherther says: so the error 2 on getservbyname_r means "no more records". In other words, means the _service_ name is not known, service is stuff like https, to get its port. I now realize the issue after looking this up - your substitute doesn't have a protocol specified. You have just bordeaux.guix.gnu.org, that is causing the issue. You seem to be having the same substitute twice, but once without protocol. But yeah, the error <lechner>jA_cOp / you have experience with both? <jA_cOp>sometimes a one-line patch to update a package is not so simple - maybe it doesn't build on the CI, or later someone responds that it was a backwards-incompatible change etc. <jA_cOp>I love Guix of course, that's why I'm here :) <lechner>good to hear. we weed them out at the door! <jA_cOp>lol, I think I'll opt out of the tattoo! :D <lechner>just kidding. i have to run. see you later <csantosb>Dummy question of the day: is it possible to create a package with several sources ? ๐ค <ieure>csantosb, Kind of, you can put origin records into the package inputs. <jA_cOp>looks like the `patches` field of `origin` also allows origins? personally I haven't done that <jA_cOp>it's origins all the way down... <vagrantc>lechner: i am a bit concerned that this might not lighten the load on the mailing list, but just add another load to IRC :) <dthompson>how do you turn those fancy animated progress meters off when running guix stuff in scripts? <dthompson>I didn't notice a flag in 'guix build --help' for this <vagrantc>dthompson: i have noticed some oddity in that too ... e.g. guix build defaults to verbosely dumping the log, guix shell tends to be fairly minimalist, guix system build is verbose, guix system reconfigure is minimalist, guix system init is minimalist ... <vagrantc>dthompson: seems like some --verbose or --debug would be nice to make the more verbose stuff less verbose or the less verbose stuff more verbose <jA_cOp>I know some well-behaved programs will check if standard output is connected to a terminal and only do progress bars et al. then, not sure if guix does this <vagrantc>obviously the code is mostly there to do one or the other, but not sure how much more work it would be to turn them on or off <dthompson>I'm looking at some CI logs that are full of the little ascii spinner text lol <cancername>Hello! I'm trying to move the store to another parttion in the installer Guix system. I tried to do this by copying every file and bind-mounting the new store to /gnu/store. However, when doing this, running `guile` gives "WARNING: /gnu/store/...-guile-3.0.8/eval.scm" followed by "no such language scheme", and never starts. How should I go about doing this? <jA_cOp>there is a `isatty?` procedure in Guile already, guix should probably use it <vagrantc>oops, meant to send something to debbugs but instead just sent it to a codeberg pull request. wheee. :) <dcunit3d>if i want to include some gawk scripts in guix home using argv like: #!/gnu/store/12/abc...hjkl/bin/gawk -f <dcunit3d>and if so, should i use url-fetch with file:/// <cancername>dcunit3d: I just use guix-home-files-service and #! /usr/bin/env -S gawk -f <dcunit3d>i think it would be mostly personal scripts. idk much about gawk or AWKPATH <dcunit3d>i don't need to complete it now, but i'd like it to function identically on different systems. <cancername>it could make sense to use guix shell in the shebang <dcunit3d>just thinking about how & whether to try it. <jA_cOp>I do the same as cancername, but if you wanted the absolute path in the shebang line, you could probably use home-files-service-type with `computed-file` and add/patch the shebang in the G expression <dcunit3d>i see. thanks. it's really helpful for processing output from gpg-agent & scdaemon, but escaping the text on CLI is no fun <dcunit3d>and i guess i would also want to use it elsewhere <dcunit3d>oh i thought you were going to reboot or something <dcunit3d>`herd start cow-store /mnt` ### Make the installation packages to be written on the respective mounted filesystem. <dcunit3d>the Guix installation media runs off of a /gnu/store, but when you walk through that guide, it has you create the volumes, disks & file systems <dcunit3d>when you start the cow-store, this directs /some/ operations to build out a new /mnt/gnu/store <dcunit3d>depending on your hard disk's partition situation (whether you would need to separate /home & other partitions to avoid data loss), then i would (1) define a system to run from USB or use the Guix ISO (2) backup your existing running system configuration (3) reboot on the ISO (4) carefully resize and note the UUID's for disks (5) mount the new disks to the FHS paths under /mnt (6) start the cow-store at mount (7) edit the system <dcunit3d>configuration so that you have the necessary changes, like a new file-system at that FHS path (8) complete the installation with `guix system reconfigure` <cancername>dcunit3d: I'm on the install Guix system, thanks! <cancername>stopping and starting the daemon did not work, so I am now following your advice, thanks! <dcunit3d>you may want to run this by more experienced users (esp. if you're worried about data loss) <cancername>dcunit3d: I'm on the install USB, so no risk of data loss. I appreciate t. <dcunit3d>the list in `(file-systems ...)` *mostly* identifies the mount points and disks that it expects to find <dcunit3d>i used to run out of inodes from /gnu/store when using ext4, but i had a lot of Guix profiles and I wasn't garbage collecting properly <cancername>yep... I just need enough space in the store to do a guix system init, so I want to move the store of the install system (in RAM) to disk :) thanks <ieure>When I reconfigure my test system using it, I get "warning: importing module (ice-9 match) from the host". <ieure>Is there some way to make it stop doing that other than "don't use match-lambda in a gexp?" <dthompson>ieure: use source-module-closure from (guix modules)? <vagrant_>just confirmed that HDMI output works without blobs on the MNT/Reform! ... it really is just the DDR training module <sneek>vagrant_, you have 10 messages! <sneek>vagrant_, efraim says: due to bootstrap issues java is x86_64 only (re: enjarify) <sneek>vagrant_, apteryx says: we're already treating the file-system with mount point '/' differently, so that's not a valid reason. <sneek>vagrant_, janneke says: thanks for dropping by on #bootstrappable with the great news about mes! it would be great to look at cross distro builds! <sneek>vagrant_, apteryx says: so yes, dynamically linked binaries are not completly pre-loaded even with the F flag, and breaks in containers. See: https://lwn.net/Articles/679536/. There was also a comment about it not working in (gnu services virtualization) :-). <sneek>vagrant_, efraim says: come join us in #guix-risc-v :)