IRC channel logs
2023-04-07.log
back to list of logs
<bjc>yeah, no difference with ‘string-append’ then <jpoiret>can you paste the /run/current-system/activation from that system? <jpoiret>i'm not sure what the easiest method would be <bjc>hmm. with --volatile, at least, i can ‘touch /run/setuids-programs/foo’ as root <jpoiret>ah shit, you'll have to find which of these scm files is the setuid programs one <bjc>even without --volatile, i can modify /run/setuid-programs. so that's a red herring <jpoiret>and you can confirm there are other setuid programs in that directory? <jpoiret>and also that the source file does indeed exist <bjc>yeah, there's like 15 or so <bjc>and the dumpcap file definitely exists. you can see it in the original paste <bjc>is there a way to tell emacs to pretty print a sexp? <jpoiret>do you have enough space on the drive? <jpoiret>actually, can you copy it manually and chmod it? <jpoiret>very funny, i know what the problem is <jpoiret>and getgrnam raises ENOENT if the group doesn't exist <bjc>so i am creating the group, but i guess setuid-programs isn't dependent on it? <jpoiret>you can check in the activation script if the user creation script comes before the setuid one <jpoiret>i'm going to go to sleep though, but imho that's the most likely culprit <the_tubular>How do I check which package pulled a specific package in /gnu/store ? <unmatched-paren>the_tubular: you mean which packages use (store path x) as an input? <unmatched-paren>the_tubular: that would be pretty much impossible to know without literally scanning the entire store <bjc>sneek: later tell jpoiret you are correct: suid activation happens before users/groups <the_tubular>I think someone here already shared how, I just didn't note it down :( <oriansj>reverse depends isn't in guix yet; just like blacklisting of packages and locking of package versions are missing as well. <oriansj>if someone wrote it up, it seems unlikely for it not to be adopted. <gnucode>hey guix, I see that ludo wants to remove goops from the shepherd. That's interesting. <bjc>he's been complaining about goops for a while. afaik it's only used in shepherd <TristanCottam[m]>Guys I'm gonna go to bed, could I by any chance get help on this problem I've had all day? <bjc>TristanCottam[m]: you'll have to post system.scm, too <TristanCottam[m]>I even get it with a minimal configuration, older commits don't work anymore <HexMachina>bjc: thanks for working on this wireshark thing! I don't know much about guix system or services but I'm trying to follow along - where is the file that shows that setuid activation comes before group creation? <bjc>i can't tell without the config, but from the error i'd guess that you're using ‘etc-service-type’ somewhere it doesn't belong <bjc>HexMachina: /run/current-system/activate is the start of boot-time activation <bjc>from there it calls a bunch of other activation scripts, based on its extensions <HexMachina>what's responsible for generating that file when you invoke guix system? <bjc>building a system consists of creating the system-service, from which all the other services fork, including activation-service <bjc>guix system (reconfigure/vm/container) just make that first activation available to the boot system, be they grub/initrd, qemu, or whatever <HexMachina>I guess what I'm getting at, is where is the logic that says that that setuid stuff happens before group stuff - and where would you need to make edits to change that order or add a dependency? <bjc>dependency can be declared in the service itself with its ‘extensions’ field <bjc>right now, there isn't an explicit one between ‘accounts’ and ‘setuid-programs’, so they can run in any order <bjc>oh, i take it back. there is no explicit way to order activations, or other system service types that i can see <bjc>seems to be that the order they run in is the order the extensions are created <oriansj>and no way to provide hints on the ordering either. <bjc>yeah. it's really not set up to be fully ordered, and in retrospect i shouldn't have assumed it was <bjc>i think i'll need to move ‘setuid-programs’ to a shepherd one shot. from what i've looked through so far, i don't think that'll cause issues <bjc>and, really, all the on-boot stuff should probably be shepherd one shots <oriansj>well setuid doesn't need tobe shepherd at all <bjc>it doesn't have to be, but it seems like a natural place for me <bjc>oh, i'm trying to fix this in guix proper, not patch over it in my system config <oriansj>well I am of the belief that hiding that block and not having the users manually set it; tends to produce more problems than it solves <bjc>the reason your config works is because you're not using any custom users or groups for your setuid stuff <bjc>i'm trying to chgrp a setuid executable to ‘wireshark’, which doesn't exist when the setuid activation runs <oriansj>well my config is rather minimal (if not overly explicit) <oriansj>just make file-like->setuid-program require to be passed the username <bjc>i don't think i understand <oriansj>when a file is setuid the command/syscall that does that needs to know what ID to associate it with. <bjc>during boot i'm getting an error when setuid activation happens because there's no ‘wireshark’ group yet, since that gets created after the setuid activation <bjc>account-activation happens about 3 steps after setuid-program-activation. i need to make it happen before, and it seems to me that moving setuid activation to a one-shot shepherd service would do that and be better overall <oriansj>well until one considers the behavior for system rollback <bjc>does that work now with the existing activation code? there's no explicit rollback handling <oriansj>well it behaves like roll forward if it is setup on every boot <darth-cheney>Hi all! Which guix package do I use to install emacs 29 with native comp? <bjc>there's no difference with a one-shot shepherd service in that way. both start from empty and populate it <darth-cheney>There is a package called emacs-next but I'm not really sure what it is for <bjc>emacs-next is the ‘next release’, which is 29 at this point <bjc>i don't know that it comes with nativecomp <darth-cheney>must be mistaken, though 29 is the version with tree-sitter and eglot in it by default right <bjc>ah, emacs-next uses libgccjit, so i'd guess it does have nativecomp after all <bjc>29 also has tree sitter and eglot <bjc>oh 28 has nativecomp, too <darth-cheney>but there is no other package that is the canonical emacs 29 release, right? at least not for now <bjc>i don't think 29 is even in rc yet <bjc>‘guix show emacs-next’ will give you its version and commit <mirai>activation-service extensions are _bad_ <mirai>it's hard to reason about them when any kind of dependency relation between other parts of the system exist <mirai>it's abused a lot to do tasks that it shouldn't be doing <mirai>but hey, to most people, it looks like a fantastic point to run some tasks before proceeding to the “main course”, which is usually a shepherd service <mirai>while it's actually a huge footgun for hard-to-diagnose inter-service dependency problems <mirai>it's also a source of maddening 'it works after a system reconfigure but doesn't after a system reboot without manually restarting it' queries <bjc>fun fact: my wireshark rule randomly stopped working at some point in the past without me noticing because the order of activations changed for some reason <oriansj>it is almost like non-deterministic behavior (outside of key generation) probably should be considered a bug. <tavoris>hi, I'm writing configuration files and I was wondering what's the best way to get the source code for channels on your guile path? I see that they exist in /gnu/store is there a way to get them added to the current profile? <tavoris>is the answer that I'm using the channel like a library package and need to write a definition to use it as such? :-) <zacchae[m]>Trying to revive an old laptop. Any idea why it might get stuck at "loading "/gnu/store/...-system/boot'..."? <zacchae[m]>Oh wait, it just moved on. Now I'm getting prints that file system errors were corrected again, even though I just swapped out the drive... <jpoiret>mirai_: I wonder how feasible it would be to switch all activations to shepherd one shots <sneek>Welcome back jpoiret, you have 1 message! <sneek>jpoiret, bjc says: you are correct: suid activation happens before users/groups <civodul>TristanCottam[m]: hi! i have to go but i didn't see your previous issues with 'guix deploy' <civodul>could you make sure it's in the bug tracker? <TristanCottam[m]>Is it possible to explicitly serialize specific fields inside define-configuration/no-serialization? Will this override the default? <mirai>TristanCottam[m]: no, otherwise what's the point of no-serialization then? <mirai>what you can use is empty-serialization after documentation <mirai>jpoiret: I was just thinking about the topic a few minutes ago <cow_2001>what are these hexadecimal hash numbers when one prepares package? i don't get it. <cow_2001>i'm trying to figure out how to create a guix guile package <mirai>cow_2001: it's from guix hash <cow_2001>i feel especially dumb when i try to read the guix manual :| <bjc>it's very differently organized than modern stuff. it feels like gnu is perpetually stuck in 1987 in some ways <oriansj>cow_2001: how can we help you do what you want to do? <rekado>bjc: it’s not like GNU is a monolith. If you’re an editor you’re welcome to help reorganize it. <rekado>though I should say that I find a lot of “modern” documentation pretty terrible <oriansj>the hexadecimal hash numbers are just that; the hash of the files as a sanity check to prevent maliciously changed source code from being downloaded and installed. (ideally the code being checked in is checked by the developer first) <rekado>I don’t see this as a difference in era but style. <cow_2001>oriansj: i remember looking at the tutorial and being thoroughly confused. maybe i should go through it again and ask questions here. <mirai>and its navigability would certainly benefit from improvements in this area <bjc>from a programming perspective, although i think the sysadmin one is not that different, finding stuff in texinfo is difficult. part of that is the way the html is formatted, part of it is scheme being dynamically typed, part of that is that reference documentation doesn't meld well with more how-to style <bjc>a constant issue i have is figuring out what type something should be when calling a procedure, and regularly have to go read the code to figure it out <bjc>not having a quick toc-style sidebar on the webpages makes navigation difficult <bjc>and overall i feel like a lot more cross-referencing could be done. maybe that's guix-specific, but it seems like that's endemic to texinfo documentation, which makes me think it's the tool more than the work <mirai>IMO, part of the problem is from using texinfo itself <mirai>it's somewhat limited and some rather prominent figures are considering moving away from it too <bjc>i don't really know enough texinfo to comment on it, beyond the obvious comment that i don't think i'm alone and texinfo was never much of a well loved project outside gnu <mirai>texinfo has its uses though, for some parts of guix it's a great fit, e.g. packages, docstrings, … (things embedded within the source) <bjc>speaking of: i couldn't find any documentation for how to extract texinfo docs from ‘define-configuration’. did i miss them somewhere? <mirai>but overall, I think something like docbook would be a better fit for documenting software projects <mirai>bjc: it's mentioned in the manual iirc, via configuration->documentation <mirai>(configuration->documentation 'foo-configuration) ; within the module that contains foo-configuration definition <bjc>thanks, i found it. and it seems like it's a manual process anyway <bjc>i was hoping there was a make rule or something <mirai>there's demand for something like that <mirai>have documentation from define-configuration be automatically inserted rather than copy-pasted <mirai>alists are for things that “can't be known in advance”, like user defined data <mirai>is it really in the hundreds? <mirai>you can take a few approaches I guess <mirai>1. leave some of them undefined, i.e. add them as needed <mirai>2. 1. + alist or lists of strings for easy way out (à la mpd or à la nginx) <mirai>3. devise an AWK/$YOUR_FAVOURITE_LANGUAGE_HERE script to autogenerate the define-configuration code <mirai>even if its partial automation <bjc>the problem with 1 is that we shouldn't expect people who use the minetest package to be guix hackers <lilyp>The typical procedure here is to provide an escape hatch – whether that be alists or a string field is up to you <lilyp>so folk can write something like (minetest-config (extra-config "this is a string that gets written to minetest.conf as-is")) <mirai>it looks amenable to use AWK to write the code here (not necessary but it's doable) <lilyp>there are a handful of services that have this exact pattern <TristanCottam[m]>I'm going to go with that. Although I like the idea of generating it automatically, it allows for less higher-level interfacing <mirai>you have documentation and the fields are neatly separated <mirai>TristanCottam[m]: if you choose the alists approach, you have mpd-service-type for reference in how the serialization is done <mirai>for strings, it's more or less straightforward <indigo-oce>what's the proper way to update guix? I've ran guix pull & guix upgrade & guix system reconfigure config.scm and it still says Your Guix installation is 181 days old... <unmatched-paren>indigo-oce: seems like your environment variables might be set wrongly <indigo-oce>hmm, are you supposed to? (also each of those commands were ran with sudo, idk if that's right) <unmatched-paren>it should be ``guix pull && guix upgrade && sudo guix system reconfigure config.scm'' <unmatched-paren>(guix pull and upgrade operate on per-user profiles, so ``sudo guix pull && sudo guix upgrade'' just updates Guix on the 'root' user) <indigo-oce>that's a bit awkward to do... can I check that it actually worked first? <indigo-oce>running guix pull && guix upgrade still results in the 181 days old message... <indigo-oce>ohhh... do I need to set the channels.scm file to have an updated commit? <civodul>er, gpg stopped working for me, saying "No secret key" <unmatched-paren>indigo-oce: try sourcing ~/.config/guix/current/etc/profile and ~/.guix-profile/etc/profile <jonsger>efraim: didn't you remove in 413097306f2197fc8bd93ba084886a41f0e3fd52 what you have enabled for ppc64le in cdba566261428d8949fcc4f7c7066a578e3009eb ? <efraim>jonsger: the 3 target powerpc helpers are target-ppc64le, target-ppc32 and target-powerpc. I didn't double check that it didn't undo what I did but guile should build for all our power architectures <indigo-oce>unmatched-paren what does sourcing those do? I've done it but how would it affect upgrading (as opposed to it sourcing channels.scm) <indigo-oce>(currently upgrading w/ channel commits set to 1.4 <jonsger>efraim: so is target-powerpc target-ppc64le + target-ppc32? <efraim>jonsger: (string-prefix? "powerpc" target) so it would even cover powerpc64-linux <unmatched-paren>indigo-oce: channels.scm just tells guix pull what to pull (there's no need to write anything there unless you use third-party channels) <efraim>jonsger: I just checked again, libstdc++ for gcc-final doesn't build on powerpc64le-linux. I did my testing with downgrading it from gcc-11 to gcc-7 <unmatched-paren>indigo-oce: whereas both etc/profile contain shell scripts that set environment variables that tell Guix things like where C libraries are found, where Guix is installed, etc <jonsger>efraim: alright, it just looked confusing to myself in the first moment :) <cbaines>when trying to build the installation image, I get: Git error: cannot locate remote-tracking branch 'origin/keyring' <civodul>cbaines: that's from current-guix, used by the installation image <civodul>you need to make sure the keyring branch is around <cbaines>git show keyring and git show origin/keyring both work <Guest70>Hello, does anyone know, how to start a dbus session. I need this for running discord with flatpak <bjc>there's home-dbus-service-type <cbaines>civodul, both of those look to be broken according to the data service comparison at least <cbaines>hopefully some more work can be done on the qa-frontpage to better describe the changes <civodul>cbaines: yes, apparently these are unrelated flaky test failures <civodul>it also shows where improvements can be made :-) <civodul>i could push a branch and manually add it to ci.guix <civodul>but it would be even nicer if it could somehow be picked up by qa.guix <cbaines>civodul, thanks, I wanted to add something to make the jump from the qa-frontpage just being about patches, to being more general <cbaines>if there's less than 600 builds per system, then the builds will be submitted automatically <cbaines>if there's more, then that'll require some manual intervention <civodul>cbaines: yeah there's more like 4k rebuilds <old>what's the easier way to pass an enivronment variable to the configure phase? <old>I need to do: ASAN_OPTIONS=verify_asan_link_order=0 ./configure CFLAGS='-fsanitize=address' <old>The CFLAGS is set in #:configure-flags, but what about environment passed to configure? <cbaines>civodul, maybe some of the code around submitting builds for patches can be refactored, then a command can be added to the qa-frontpage so that you can manually submit the builds for an issue. That's not ideal, but maybe a good next step. <old>would (add-before 'configure 'configure-environment (lambda _ (setenv "ASAN_OPTIONS" "verify_asan_link_order=0"))) work? <Guest70>bjc I put it into my config, but i get " home-dbus-service-type unbound variable <bjc>make sure you have ‘(gnu home services desktop)’ in your ‘use-modules’ decalaration <bjc>s/decalaration/declaration/ <Guest70>(gnu home services desktop form) , but i get the error no code for module (gnu home services desktop form) <bjc>it's ‘(gnu home services desktop)’ not ‘(gnu home services desktop form)’ <bjc>btw, you can search for system services with ‘guix system search’ and likewise for home services with ‘guix home search’ <bjc>those will also tell you what module they're in, though you have to convert the path to a module expression, but that's straight-forward <Guest70>bjc I just added form, because it asked me, if i forgot form <bjc>can you paste your config file somewhere? <bjc>oh, sorry, i thought this was a home config for some reason <Guest70>bjc I have no home config, yet, I just want to get dbus starting, but i am failing <Guest70>I tried dbus-launch and then population the env variables, but it did not help <bjc>there's a ‘dbus-root-service-type’ for system-level stuff, but that's included in ‘%desktop-services’, which it appears like you're using <Guest70>bjc I am gettin the error Faild to connect to session bus: org.freedesktop.DBus.Error.NotSupported, when starting discord <Guest70>Using X11 for dbus-deaemon autolaunch was disabled at compile tiem., <Guest70>bjc It is really frustrating for me. How have you overcome these difficult problems? <bjc>you can configure shepherd to autostart dbus when you log in, and the easiest way to do that is with guix home <Guest70>_ctb Can't i just start the process in the shell? <bjc>tbh, i don't remember having this specific issue, but maybe i was already using home-dbus-service-type <bjc>you can just start it in the shell, but you'll have to do that every time you log in somehow. xinitrc or autostart or whatever <Guest70>bjc but even that does not work and that is weird <Guest70>bjc it works, but the error is still there, when starting discord <bjc>this may be a flatpak issue, then. do you have a desktop-portal installed? flatpak tends to need that <bjc>i don't have the error when i start discord from the command line <bjc>hmm, that may be a red herring. i don't have that installed on my guix box either <bjc>from a terminal, do you see anything in ‘env | grep DBUS_SESSION_BUS’? <bjc>this may be an issue with that environment variable not being set early enough <Guest70>bjc That is definetely empty. That is why i started dbus-launch and then filled the variables <bjc>in the same terminal session, can you set that variable and run discord? <bjc>so, you have ‘dbus-daemon --session’ running, DBUS_SESSION_BUS_ADDRESS pointing to its socket, and starting discord still shows that error? <TristanCottam[m]>Is it possible to refer to the intermediary match input object inside match-lambda? <TristanCottam[m]>Or should I specify match and lambda separately? In the context of a Shepherd service definition. <unmatched-paren>(the way MATCH and MATCH-LAMBDA do record matching is dependent on the order the fields are defined, which makes it... quite unwieldy) <unmatched-paren>unfortunately there's no MATCH-RECORD-LAMBDA (that should be A Thing...) <unmatched-paren>so you'd want to do (lambda (rec) (match-record rec <RECORD-TYPE> (FIELD-SPECS ...) BODY ...)) <TristanCottam[m]>Is it required to specify all fields in record-type, or can I just specify the ones I need in a certain context? <Guest70>I have installed python as package. But i cannot start python, it is not found. <Guest70>When i do guix install python, i can start it, why is thet? <mekeor[m]>Guest70: how do you know you have python installed? <Guest70>unmatched-paren I put it into my configuration and added it as package, then i reconfiguered the config <Guest70>unmatched-paren sudo guix system reconfigure configuration.scm, i have the file in my home folder <mekeor[m]>we need to see the part of configurarion.scm that ought to install python <unmatched-paren>not really; just do (match-record record type (fields ...) [newline, two spaces] body ...) <unmatched-paren>if there's not enough space for FIELDS, RECORD, and TYPE on one line, put the list containing FIELDS on the next line with four spaces <Guest70>unmatched-paren mekeor[m] I fixed it, i think i just needed to run the commands for the env variables in the nix profile <TristanCottam[m]>But in Emacs, AFAIK following .dir-locals.el, the body gets the same indentation as record <unmatched-paren>looks like (put 'match-record 'scheme-indent-function 2) <- the 2 should be a 3 <Guest70>Can anyone recommend a better sync service than dropbox? <Guest70>TristanCottam[m] cool cool, will look into it <Guest70>Does anybody have an idea, how to install python3-gi on guix in order to run the dropbox daemon? <eyJhb>No clue why I sent ja instead of en version. <eyJhb>unmatched-paren: Oh cool, is that the only/best way? <TristanCottam[m]>I'm starting to get the hang of all this Scheme nonsense, this feels awesome <eyJhb>unmatched-paren: Would require I have guix installed :D <eyJhb>Just still in the curious state, currently on NixOS <Guest70>mekeor[m] i have installed it, how can install the package now? <eyJhb>I should setup a custom laptop and play with Guix. Feels kind of cool, but I am unsure if I have grasped the "advantages" of Guix vs. NixOS <TristanCottam[m]>No, the serialization is quite basic, but just making sense of everything was quite a challenge <Guest70>mekeor[m] but i am struggling with importing it <mekeor[m]>Guest70: first, run "guix import ..."; if needed save the code and edit it so that the package builds; try installing with "guix package -f yourfilename.scm". i.e. you will need to write a package definition in scheme. <sysfu>I'm having a problem starting Xorg from a VT using the sx script. It's an Xorg configuration issue where I have no mouse and keyboard after starting X, and am unable to even switch to a virtual terminal. Forced to hard poweroff and reboot to recover the system. <sysfu>I can run Xorg -configure and write out a configuration file, but when I try to test that, same problem with no mouse, no keyboard. <sysfu>Xorg when enable via /etc/config.scm as configured during the graphical installation worked without issue. <mekeor[m]>sysfu: sounds like you need a x driver or so <mekeor[m]>sysfu: do u have a xorg service system wide? <sysfu>mekeor[m]: maybe this driver was removed when I removed the gdm and xorg components from my config.scm? <sysfu>mekeor[m]: I didn't think I wanted or needed an xorg service system wide, becuase I want the system to boot to a virtual terminal, not an X/gdm environment. <sysfu>I'm using the sx package to start Xorg. <mekeor[m]>sysfu: did you install any xf86 driver into your user profile? <unmatched-paren>TristanCottam[m]: hmm, it looks like there is indeed special syntax in this conf file :( <sysfu>mekeor[m]: just the mouse one iirc, but that's dead too. Let me check to make sure both mouse and keyboard xf86 drivers are present. <mekeor[m]>ACTION starts a user-owned x with "xinit" from VT1 <unmatched-paren>TristanCottam[m]: so i think the best thing to do would be identify the most important variables, add those as record fields, then add another field that can accept a file-like object which is appended onto the generated configuration <sysfu>mekeor[m]: I had profile package for xf86-input-mouse but not xf86-input-keyboard. Shouldn't my mouse still have work in that case tho? Installing the keyboard one now... <sysfu>mekeor[m]: also trying to get sshd running so I can login remotely and kill X without having to hard reset the computer. <unmatched-paren>that way you could have a record and then a "fallback" text input for when the record doesn't provide the field you want <mekeor[m]>sysfu: i wonder if you need something like libinput or so <sysfu>mekeor[m]: i need to figure out how to enable SSHD I can login remotely. <unmatched-paren>Pas beau mais la meilleure chose pour faire. (not sure if "pour" is correct there; i can never figure out how to translate "to <verb>", the construct's used for so many different things in english :P) <mekeor[m]>sysfu: just add opensshd service to your system config and reconfigure <mekeor[m]>sysfu: concerning x drivers, unfortunately, tbh, i don't know much about them (by heart) <jpoiret>unmatched-paren: i would say "la meilleure chose à faire" <mekeor[m]>talking about french, i hope folks know how to pronounce guix :D <unmatched-paren>Does pronouncing 'geeks' for Guix make sense if you read it as a German word...? <mekeor[m]>ACTION begins reading "oi" in"jpoiret" as oo-a, instead of oh-ee <unmatched-paren>mekeor[m]: i don't really see a way to read it as 'geeks' with English pronunciation --rules-- barely coherent mess <unmatched-paren>Before I saw the pronunciation explicitly mentioned I instinctively pronounced it as "GOO-iks" <Guest70>mekeor[m] I think, i have to read, how to check the package definition <sysfu>mekeor[m]: thanks for your help. I'm stuck trying to enable ssh server, have to read some docs to figure that out. <mekeor[m]>sysfu: or just grep: sudo herd status | grep ssh <mekeor[m]>unmatched-paren: "geeks" in english is not ambivalent, imho <mekeor[m]>unmatched-paren: there is also this pronunciation notation which is based on english. dont know its name... <mekeor[m]>unmatched-paren: in french (and italian), a G is pronounced as J (like jungle) when it's followed by E or I. to make it pronounce as G (like god), you need the U after G. so, in french, "guix" is not pronounced as gwix, but just like english "geeks" <mekeor[m]>unmatched-paren: the "ee" pronunciation rule in english is coherent <mekeor[m]>mekeor[m]: (also consider the GE in bourgeoisie) <TristanCottam[m]><unmatched-paren> "Tristan Cottam: so i think the..." <- I don't mind creating a basic parser, I'm quite happy with my alist setup. <sysfu>mekeor[m]: 'herd start sshd' yields 'service 'sshd' could not be found' <sysfu>mekeor[m]: there is no sshd process running. <unmatched-paren>TristanCottam[m]: in fairness i doubt "guadaloupe" and "Guatemala" originated from french; much like it makes sense for the word "saboteur" to be pronounced by english speakers as in french <sysfu>mekeor[m]: Trying to add it to config.scm as per the example 'bare bones' setup here yields unbound variable errors when checking config.scm with --dry <TristanCottam[m]>A funny one is "connoisseur", which is actually written "connaisseur" in French <TristanCottam[m]>I can't imagine it's anything else than a spelling mistake which caught on <jlicht>just an FYI, if someone is using the tuxedo-keyboard kernel module; it seems that it tweaks things w.r.t. fan curves, which makes your laptop both louder and warmer in my experience <mekeor[m]>sysfu: paste config.scm and error please. also, did you add (use-service-modules networking ssh) (use-package-modules screen ssh) ; or something semantically equal? <sysfu>mekeor[m]: Let me see if I can get it off the system I'm troubleshooting via wgetpaste util <sysfu>I'm chatting on IRC using a differenc computer. <jlicht>correction: tuxedo_io kernel module, which is part of our tuxedo-keyboard package <sysfu>mekeor[m]: there was already a user-service-modules line created by graphical installer that included networking and ssh modules <tavoris>I have my channels being set with the home-channels-service-type, when I run `guix pull` it shows my additional channel in the "Building from these channels:" list, but when I run `guix describe` it's not listed. Am I missing something? <TristanCottam[m]>Is it acceptable to generate service configuration parameters on the fly, or should it be done manually, committing the generated configuration only? <TristanCottam[m]>I noticed Minetest conveniently documents all configuration options in a machine-readable format, and I wonder if I could simply write a parser for it to generate the configuration definition on the fly. <mirai>I think you'll want to write the parser and commit the generated config <mirai>bonus if you include the parser as well <TristanCottam[m]>So configuration fields should be specified literally, rather than on-the-fly generation? <mirai>you can raise a discussion at guix-devel <unmatched-paren>TristanCottam[m]: here's an idea, if you're up for it: parse the specification with a macro and have it output the appropriate DEFINE-CONFIGURATION >:) <mirai>if you're not a greybeard/emacs veteran or are too attached to the gui ways, I recommend thunderbird (or its ice-??? equivalent) and a public-inbox NNTP mirror (like yhetil.org) to access the MLs <TristanCottam[m]>unmatched-paren: I don't know about macros yet, but that was my idea, yes. <unmatched-paren>TristanCottam[m]: i suspect you'd need to use SYNTAX-CASE, which is the most complex (and subsequently most versatile) way to define macros <TristanCottam[m]>Well I'm discovering the bottomless pit of Emacs and I wouldn't mind going that way, apart from that I like GNOME and consistency with it. <unmatched-paren>SYNTAX-RULES lets you make simple things but if you're in a situation where you need to actually write Scheme code that operates on "syntax objects" (as you will here) you need SYNTAX-CASE <mirai>ACTION doesn't recommend diving into macros for scheme starters <apteryx>zrythm updated on master, for anyone interested <TristanCottam[m]>Well falling down the Guix rabbit hole already melts my brain, I think I can take more :) <unmatched-paren>TristanCottam[m]: you should first look into DEFINE-MACRO and why it should be avoided, then SYNTAX-RULES and why it's much better, and then go on to SYNTAX-CASE <mirai>I still don't think I fully grok the macro workings <unmatched-paren>DEFINE-MACRO simply lets you define a sort of expand-time procedure that returns an sexp which is treated as Scheme code <mirai>TristanCottam[m]: word of advice, if you happen to understand little of what's written about macros in the guile manual you're not alone <unmatched-paren>SYNTAX-RULES sort of lets you "match" on syntax elements; it's far more abstract than DEFINE-MACRO <apteryx>TristanCottam[m]: I haven't actually tried Zrythm :-) <mirai>advice 2: you can peruse Racket's documentation about macros, even though it isn't guile it helps immensely for understanding how “the thing” works <unmatched-paren>SYNTAX-CASE is how SYNTAX-RULES works under the hood, and it's probably the least abstract of the lot <apteryx>I've used Ardour in the past, it's a shiny and capable DAW. <unmatched-paren>SYNTAX-CASE actually lets you write Scheme code that manipulates syntax objects, which are a bit like sexps enhanced to remove the problems associated with the likes of DEFINE-MACRO <mirai>finally, if you happen to become a macro expert and know how to write, the guile docs about macros could certainly benefit from some polishing <unmatched-paren>TristanCottam[m]: no, SYNTAX-CASE will atomise your brain if you don't know SYNTAX-RULES <TristanCottam[m]>unmatched-paren: I'd rather stay away from any brain atomization action for now. <unmatched-paren>oh, by the way there's also IDENTIFIER-SYNTAX, but that's a pretty simple abstraction over SYNTAX-RULES and not really a thing you need to know <unmatched-paren>basically (define-syntax floob (display "Floob!\n)) will make just the symbol 'floob' on its own expand to (display "Floob!\n") <unmatched-paren>it's sometimes useful when you want to make a thing that looks like a constant but isn't <unmatched-paren>TristanCottam[m]: C macros are nothing like Scheme macros. Whatsoever. <jlicht>does match-record not work with guile's define-record-type? <unmatched-paren>You have committed thoughtcrime by considering the very possibility. Please proceed to the brain-scrambling chamber. :) <TristanCottam[m]>unmatched-paren: Obviously the code-as-data concept is quite alien to C. <mirai>jlicht: match-record is for the type* <unmatched-paren>TristanCottam[m]: well, (identifier-syntax (display "Floob!\n")) is equivalent to: <unmatched-paren>(lambda (syntax-object) (syntax-case syntax-object () (_ #'(display "Floob!\n")))) <TristanCottam[m]>Is there a shorthand for mapping a procedure with 2 arguments to the key (car) and value (cons) of each item in an alist? <unmatched-paren>TristanCottam[m]: import (ice-9 match) and use match-lambda, like so: <unmatched-paren>(map (match-lambda ((head . tail) #| do stuff here |#)) #| list here |#) <NewUser-Basic-Qu>Question: If i am in Guix shell in a guix git repository and do "./pre-inst-env guix system reconfigure some.scm" will it take (build) from the directory(git repositry) it is in? <unmatched-paren>TristanCottam[m]: oh, yeah, it appeared as "s//`/, s//`/, s/cons/`cdr`/" <tavoris>this patch was added last year to warn prevent channel downgrades. What conditions cause this to occur? <tavoris>is this happening because I'm trying to install guix with the home-environment? is it just always going to pickup outdated packages for guix? <TristanCottam[m]>Yeah my brain is a little fried from all day, but that indeed doesn't look very simple. <tavoris>yeah, should I not do that? is it provided regardless of the home-environment? <TristanCottam[m]>unmatched-paren: I can't remember if you helped me with this already, but can you help me understand how I can troubleshoot `guix deploy` suddenly erroring with no apparent cause? <unmatched-paren>tavoris: don't install it with home, system, or ``guix package''; always use ``guix pull'' <TristanCottam[m]>I mean, just troubleshooting a Guile error returned by a Guix command in general. <tavoris>unmatched-paren: so is it available in environments without needing to specify it? <tavoris>unmatched-paren: so it's just not available in `guix home container ...` environments? <tavoris>I just tested, getting "command not found" <unmatched-paren>tavoris: if you do ``source ~/.config/guix/current/etc/profile'' within the container you should be able to use it <TristanCottam[m]>I get this error even with a minimal configuration, it happens all the time <tavoris>`~/.config/guix/current` is not shared by default <zamfofex>Hello, Guix! I had an interesting thought the other day: Would it be unreasonable to provide ‘guix package’ tarballs somewhere for people not using Guix? Or perhaps some other way to install and test/try packages from other distros. I feel like that would be a really neat way to get more people interested in Guix. Kind of like a Snaps or Flatpaks, but in a way that allows people to try out programs without installing any tools. <zamfofex>Yeah, sorry, I meant ‘guix pack’ instead of ‘guix package’! <zamfofex>I noticed some packages take a long time to generate tarballs for. E.g. try ‘guix pack -RR icecat’ <unmatched-paren>zamfofex: well, if you wanted to provide some sort of substitute farm for ``guix pack'', you'd probably need some sort of Googlesque data centre <zamfofex>I suppose so! I just feel like given the tree of dependencies and the substitutes for the dependencies already downloaded, it shouldn’t take as long as it does to generate the tarballs. <Guest19>Hi. I found new information on the already closed issue https://issues.guix.gnu.org/43610 . I sent the "unarchive"-command to the control server and afterwards sent a comment to 43610@debbugs.gnu.org . The comment has not appeared on the website yet. Do I also have to send the "reopen"-command first or does it just take time to review my comment before it can be displayed? I did not get a reply after sending the mail with the comment.. <civodul>Guest19: hi! i think you have to unarchive + reopen before you can comment <unmatched-paren>zamfofex: just to clarify what i was saying: guix pack tarballs contain every single one of their dependencies. <zamfofex>I understand that. I mean that even if I already have all such dependencies, it takes quite a while to generate the tarball for some packages. <civodul>Guest19: the issue is from 2020 though; perhaps opening a new one would make more sense? <zamfofex>unmatched-paren: Also, some more thoughts: I remember once sharing such a tarball with a friend of mine, and he felt it was kinda unfortunate that the tarball had to include all of the dependencies when he already had some of them installed on his system. I don’t fully disagree. It does feel unfortunate that e.g. glibc and openssl have to be included when he already has a compatible version installed. <Guest19>i can make a new one, even though it is directly connected to the old one. <unmatched-paren>zamfofex: i suspect the time is nothing to do with building the packages; if you already have them in the store, then guix will never try to rebuild them <zamfofex>unmatched-paren: A potential solution I thought of (regarding not having to include glibc,openssl&al): It would be interesting if there were some way to optionally represent a “pre‐installed dependency” in Guix as a store item. The store file system entry would just be a symlink to the file system root. The idea would be this could be used as a graft for glibc&al when generating tarballs, and when using Guix on a foreign distro. <zamfofex>unmatched-paren: I know it doesn’t have anything to do with building packages. I’m just lamenting that it takes so long, is all. I don’t know what specifically causes it. <unmatched-paren>i don't know much about pack, to be clear (i've never used it) you're probably better off discussing this with someone more qualified :) <zamfofex>Sorry if I’m a bit scatterbrained today, but another thought: It’d be interesting if Guix could generate static executables somehow. The advantage over ‘guix pack’ would be that it’d be much more sparse: You don’t have to include files the package doesn’t use. More strongly, you don’t have to include symbols the package doesn’t use. <zamfofex>I noticed musl is packaged, but it doesn’t seem to be used for anything, and it doesn’t seem usable for anything either. <Guest70>I have the error of, wenn building my package: <Guest70>guix pakace errro: cannot install non-package object: #guix<unspecifued>. What does it mean? <Guest70>I have the error of, wenn building my package: <Guest70>guix pakace errro: cannot install non-package object: #guix<unspecifued>. What does it mean?♑ <unmatched-paren>if you are, you need to make the last expression in the file a package object, not a DEFINE <Guest70>sorry for sending my message two times <Guest70>unmatched-paren how do i do that with: (gnu package pyobject) ? <Guest70>unmatched-paren how do i make the last object a package? <Guest70>unmatched-paren hmm, that worked now thank you, the only new problem i have that it could not download pyobject from files.pythonhested.org/pakcages etc <zamfofex>Some more (random) thoughts: I have had “oasis” (distro) on the back of my mind for a while now. It seems to share some similarities with Guix, while being entirely different at the same time! It will always build static binaries, though. Like Guix, it uses a declarative approach to install packages (similar to ‘guix system reconfigure’, from what I understand.) <zamfofex>Perhaps this is a good thing, but it driven by a particular set of principles. And unfortunately, they prevent it from being completely useful for me. More specifically, it avoids packaging “complicated” software. <zamfofex>Though I will say: I feel like I don’t see any flaws with the approach it takes compared to Guix, I just wish it were more compatible with existing build systems. (It doesn’t use projects build systems, it will instead has a list of source files for each package.) <unmatched-paren>Guest19: This page is no longer available. It has either expired, been removed by its creator, or removed by one of the Pastebin staff. <Guest70>unmatched-paren my last one is the right link to my package <unmatched-paren>(although you should use PYPROJECT-BUILD-SYSTEM, not PYTHON-BUILD-SYSTEM <unmatched-paren>Guest70: can i also see the output from attempting to build the package? <zamfofex>I changed the hash a bit from Guest70’s package definition. <unmatched-paren>Guest70: okay, so this is weird: seems like the file uploaded to pypi.org is called pyobject-1.2.1._.tar.gz (note the underscore) <unmatched-paren>Guest70: so what you'll want to do is change (pypi-url "pyobject" version) to (pypi-url "pyobject" (string-append version "._")) <tavoris>so turns out adding guix to my profile manually was causing it to do a downgrade loop. it warned me but I didn't understand the warning lol. maybe this is something that could be explicitly prevented? <unmatched-paren>tavoris: i actually sent a patch doing just that to the guix mailing list a while ago <tavoris>nice, great minds and fools and all that <zamfofex>unmatched-paren: Seems like you have an extra “.” there, no? <unmatched-paren>Guest70: so it should actually be (pypi-url "pyobject" (string-append version "_")) <zamfofex>At any rate, sorry for the disorganized thoughts. I wish I could have been a bit more coherent. <mekeor[m]>sysfu: this is the command that i use: xinit -- ~/.guix-profile/bin/Xorg :0 vt1 -keeptty -configdir ~/.guix-profile/share/X11/xorg.conf.d -modulepath ~/.guix-profile/lib/xorg/modules -logfile ~/some/path/xorg.log <mekeor[m]>sysfu: i have installed these packages as user: xf86-input-libinput xf86-input-wacom xf86-video-intel xinit xorg-server <Guest70>unmatched-paren I did, what you said, but the ubuild is still failing <Guest70>unmatched-paren i will go to bed for now, thank you for your help :)