<khassanov>Hey guys! Could you share how can I set up an automatic Wi-Fi connection for a computer without desktop services? Maybe one can give an example like a piece of config. I just learn Guix. Thanks!
<raghavgururajan>lfam: Only with dhcp-client-service-type and wpa-suppicant-service-type? Do you know how to  connect specifically in 5GHz frequency  set custom dns server  spoof mac address? Thanks!
<lfam>In my experience, the frequency used by a wifi network is set by the access point, not the client
<abcdw>what is a proper way to start user's shepherd automatically?
<civodul>janneke: dunno but i think we're usually slightly below 300 and here ERC says 362
<civodul>abcdw: i do that from my ~/.xsession but i'm not sure it qualifies as a "proper way" :-)
<abcdw>civodul: curios if there is a some established way to do it. In systemd "user's systemd" IIRC is not a separate process and always avaliable with systemctl --user SUBCOMAND and you don't have to care about starting user's systemd at all. Just trying to understand, when I have to run my user's shepherd :)
<jlicht>abcdw: I start shepherd in my bash profile, if there is no XDG_RUNTIME_DIR/shepherd/socket yet
<jlicht>seems to work well enough for my workflows :-)
<abcdw>civodul: I read the doc about extensions mechanism and few patches/mails about possible improvements to it. It seems some use cases is hard to implement in current version of extensions. For example I declare user-space-shepherd-service-type, which extends shepherd-root-service-type, but how to understand for which users I have to spawn new shepherds?
<abcdw>I can create another service this-host-users-service-type, which will extend both user-space-shepherd and account-service with list of accounts needed in the system, but it is a little hacky, and it seem that it will "break" users field for OS record (if someone inherits from the record and would like to add new user with users field the new user won't go to user-space-shepherd).
<civodul>in the option i outlined, account-service-type extends shepherd-root-service-type, because account-service-type is the one that knows about user accounts
<civodul>now yes, there are things harder to achieve
<civodul>but the general approach where any service can change anything in the system seems wrong to me
<civodul>i think this needs to be structured, not the wild west :-)
<refpga>Hello, has anybody encountered problems with sddm recently? My config broke without any changes to the config file. I get the error that 'elogind' is not provided by any service, which is required by 'xorg-server'.
<abcdw>civodul: No doubts about the structure, services approach is very nice, but I didn't understand the option you outlined. Do you mean that I should add extension to account-service-type, which will create user-space shepherds?
<leoprikler>I think you'd write a system shepherd service (format #f "shepherd-~a" user), which spawns a shepherd service for that user
<leoprikler>I'm not sure how exactly that would go though, since you'd have to spawn that service at user login.
<leoprikler>I'm not exactly sure how systemd does this, but there's interaction with logind for sure.
<efraim>You could spawn it running as that user but I'm not sure how you'd be able to interact with it as your user
<leoprikler>fwiw i already have shepherd running on login through gnome autostart, so that's not really an issue
<abcdw>leoprikler: Not exactly what I want. I want a user-space-shepherd-service-type, which creates a new record in shepherd-root-service-type for each user defined in account-service. And it will start on boot, not login time.
<leoprikler>so you'd start everyone's shepherds regardless of whether they're logged in or not? I don't think that
<abcdw>For some systems it's undesired behavior, that's is why I try to implement it with a separate service, which can be included if necessary.
<leoprikler>Well, let's assume a family PC used by three people with three separate accounts. If one of them spawned a shepherd service from their init.scm, the other ones would have that running even if that person wasn't using the PC and wasn't logged in.
<Anonymous__>How can i setup a script to run during eh boot time in sheperd?
<civodul>wleslie: yeah it's weird; this is for a user of libbfd outside Binutils?
<abcdw>leoprikler: Seems ok to me. Maybe that person wants to have his bitcoin miner up and running all the time PC is up?) If not, do not include user-space-shepherds in your OS config. Anyway, despite the usage of such service, I more interested in implementation details of the case when service one depends on the data of service two and extends service three.
<civodul>(bfd is not really meant to be used outside binutils)
<rndd>abcdw: ohhhh, there are user-space services?
<wleslie>it turns out that when you co-author the ELF spec, and later have to design a filesystem, evidently you just kind of C-k C-y
<leoprikler>abcdw: how would you even know about this bitcoin miner tho? Those shepherds would have to run the user's init.scm, would they not?
<abcdw>rndd: Depends on what you mean by user-space services)
<wleslie>I have a bfd built from source outside guix, I'll see how that worked
<rndd>abcdw: is there possible to run, for example nginx as user0, and it will be isolated from othe users (of cource u have to open tcp ports as admin, but i mean something like docker).
<abcdw>leoprikler: Why do I need to know? I don't see a lot of difference between case, when person logged in and logged out to have shepherd runned and the case, when shephered was launched during the boot.
<abcdw>civodul: 3 cases: disabled; enabled and populated only with provided input; enabled and populated with provided input and account-service
<morgansmith>leoprikler: nah, currently they belong in .config/emacs/eln-cache or in the emacs lib dir. that's just what comp-eln-load-path is set to. Maybe I'll give eln it's own folder then
<abcdw>civodul: don't plan to add to %base-services. I heard that service will be automatically instantiated if its service-type extended by another service. Am I wrong?
<leoprikler>If Emacs already says it should go into $prefix/lib/emacs/eln or anything among those lines, please try to respect that :)
<maav>apteryx: VERBOSE seems to fit into what you want, as it shows the test log when it fails
<leoprikler>abcdw: It sounds like you're overengineering a rather complicated solution: why not have (lingering-shepherd-configuration (users "abcdw" "jlicht" ...)) and for those given users simply check whether they exist?
<abcdw>leoprikler: it's very good solution and I already thought about it, but I want to achieve following: I define OS, someone inherits from it and adds users, all non-system user gets lingering-shepherds automatically, maybe I'll implement it more explicitly, but that was my original idea.
<maav>that isn't an environment variable but a make variable, you have to define VERBOSE=something before the make invocation
<maav>nonetheless, it depends on the log file being created
<apteryx>in my experience GNU Make treats 'make VAR=value' the same as VAR=value make; I've tested the variable to be effective on a well-haved test (works both ways).
<apteryx>I think it's our custom SCM test driver that could handle exceptions better
<leoprikler>abcdw: I don't think that's a good way to approach operating-system creation. You could write your service in a way, that the extender can add their own lingering shepherd services or extend lingering-shepherd-service type.
<maav>apteryx: no, they aren't the same thing, the first VAR is a macro definition (think of it as placed at the end of the Makefile), the second one is an environment variable (which some standard variables take into account like CFLAGS)
<maav>the first shouldn't escape make internals if it isn't used on the actual target, the latter will be available to the processes called by make too
<maav>with a target calling "env" you'll see VAR on the second case but not on the first one
<leoprikler>imo using the "one service per user" model you could also do it the mingetty style, and simply instantiate that service a bunch of times
<maav>(unless VAR is assigned on the file, which would mean that only the first case would work)
<abcdw>leoprikler: agree, looks like a good solution. I alread think for few days about using a function for OS creation instead inheritance. That's way I will be more flexible on what happens under the hood, without overengineering.
<rekado>I need to go now, but I’ll apply it later.
<zimoun>rekado: Thnaks, feel free to tweak the commit message. :-)
<zimoun>civodul: Hi! Giving a look at bug#45615, it seems that SWH changed something. Well, I am confused because ’visit-snapshot-url’ returns nothing and I was expecting the field ’snapshot-url’ containing a string or #f and not #<unspecified>. See (origin-visits (lookup-origin "https://github.com/Genivia/ugrep/")). What do I miss?
<mdevos>The following error from ‘guix package -u’ has me puzzled somewhat: https://paste.debian.net/hidden/6da5c3d9/. gtk+2 and gtk+3 should be co-installable, right? I presume the conflict detection logic just looks at the name and version, so if the gtk+@2.* package were named gtk+2 and the gtk+@3.* were named gtk+@3.*, there wouldn't be a problem?
<civodul>zimoun: i see "status: ongoing" for this one, so maybe snapshot-url will become a string once the snapshot is complete?
<zimoun>civodul: the problem is: instead of a clean expected message, because of that, “guix lint -c archival” returns an ugly Backtrace
<zimoun>The function swh-url fails uglily because its argument path is not a string.
<zimoun>from my understanding, the define-json-mapping <visit> should return a string or #f for snapshot-url, not #<unspecified>.
<yjftsjthsd>Darn, I hoped you would tell me that there was a full Guix System image for it already (kinda like nixos has https://mobile.nixos.org/index.html). I would indeed expect guix running on another OS on pinephone to work just like any other LInux-on-aarch64
<apteryx>civodul: Could it be better to use the Guile '#:guess-encoding' parameter of the call-with-input-file procedure (used in with-atomic-file-replacement called from substitute) instead of hard coding UTF-8 as default via the %default-port-encoding fluid?
<apteryx>the doc says it tries to guess via the file-encoding procedure else uses UTF-8.
<apteryx>ah nevermind; this looks for an Emacs-like character coding declaration; not very useful.
<apteryx>I thought it'd peek at the binary BOM of the file or something
<jgart[m]>does anyone know of an extant icecast-service-type lying around anywhere?
<nij>jgart[m]: Regarding making a channel for suckless utils, there are many user patches on their websites. By choosing different patches, there will be many different versions. How would such channel be possible? Do we need to package one for each configuration?
<civodul>apteryx: yes, file-encoding is not super useful
<jgart[m]>nij: I imagine the best way would be to inherit from a master suckless package each time with different patches. If someone knows a better way please chime in. I would love to know. I'll be back online later
<jgart[m]>i.e. a master package definition for each program. All forks would inherit from upstream dwm with different patches
<lfam>jgart[m]: What rekado said, and also, at this point, it's not very useful. We've already imported or copied the bulk of the trivial packages from Nix, and the importer cannot handle any sort of complication in the nix package
<lfam>By complication, I mean things like custom build phases, etc
<lfam>In almost every case it will be easier to read the Nix package and rewrite by hand for Guix
<jgart[m]>Do you use snippets to generate boilerplate for a new package?
<cbaines>system is the column that'll be useful for limiting to specific systems
<cbaines>I think this will count failed aarch64-linux and armhf-linux builds for some staging evaluations: SELECT COUNT(*) FROM builds WHERE system IN ('aarch64-linux', 'armhf-linux') AND status = 1 AND evaluation IN (10974, 11190, 12550);
<lfam>Yes, I think so. I did change the tzdata, which will cause many rebuilds, but I'd still like to reschedule everything, in case there are some spurious failures of packages that don't depend on tzdata