<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>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
<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...
<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
<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
<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.
<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.
<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]>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)
<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
<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
<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>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
<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>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 firstname.lastname@example.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?♑
<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.)
<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>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 :)