IRC channel logs


back to list of logs

*Digit_ sees guix.el and :.)
*jgrant ordered a RYF-compliant Wireless-N adapter today, so he can drop this bulky Wireless-G'r that he's bee dealing with for far to long. :^)
<mark_weaver>jgrant: that's good!
<jgrant>too long*
<jgrant>Yeah, I'm pretty excited in that I can take this machine with me soon without worrying of accidently breaking this/the adapater as previously I've concerned myself with.
***Digit_ is now known as Digit
<jgrant>Okay, I'll likely look into setting up a torrent for GSD tomorrow if Gabou doesn't beat me to it. :^)
<jgrant>Peace people. o/
<mark_weaver>jgrant: we've decided to call it GuixSD, btw.
<ewemoa>Digit: did you see this one already?
<Digit>my browser seems to think i've opened that in the past at least. thanks, that's got me diving in, rather than all the reading around the edges. :)
<ewemoa>cool -- it's hard to know what to ignore at first!
<ewemoa>ahhh, /root/.config/guix ... that's where things are hidden :)
<mark_weaver>ewemoa: that guide is outdated in some ways and has some mistakes also.
<mark_weaver>e.g. /nix/store --> /gnu/store (outdated)
<mark_weaver>(we used to use /nix/store, but now we use /gnu/store)
<mark_weaver>you put $HOME/.guix-profile/bin in PATH
<mark_weaver>you can write ./pre-inst-env guix ...
<mark_weaver>but they write ./pre-inst-env scripts/guix ...
<mark_weaver>(which also works, but is more typing than you need)
<mark_weaver>~/.config/guix is where the updates from "guix pull" go.
<mark_weaver>I don't use "guix pull", but instead prefer to run directly out of my git checkout using ./pre-inst-env
<mark_weaver>so I don't have ~/.config/guix at all.
<mark_weaver>and remember that the daemon is normally the only thing that you run as root.
<ewemoa>mark_weaver: thanks for the diffs!
<civodul>Hello Guix!
<mark_weaver>hi civodul!
<mark_weaver>can 'patch' be updated in master, or is that for core updates?
<mark_weaver>core-updates I guess.
<mark_weaver>we should update to patch-2.7.4
<mark_weaver>anyway, I need to sleep now.
*mark_weaver ---> zzz
<Gabou>jgrant | Okay, I'll likely look into setting up a torrent for GSD tomorrow if Gabou doesn't beat me to it. :^)
<Gabou>Agrh he is gone? :(
<civodul>mark_weaver: core-updates, yes
<Gabou>Digit: thanks for the video conference :-)
<civodul>indeed, that sounds like a nasty vulnerability
<Digit>yvw Gabou
<ewemoa>what is the following missing for building a new package in an installation of gsd 0.8.1 running on virtualbox? 1. create appropriate test.scm file 2. in same dir, guix build -L . test.scm
<jpt4>Salutations, #guix.
<jpt4>I write to report a successful GSD install and boot, and to ask a question about user passwords.
<jpt4>It strikes the security conscious as imprudent to store passwords as plaintext in the main system /etc/config.scm, but using unix "passwd" to write to .shadow bypasses guix.
<jpt4>Is this a necessary divergence, or can guix access and manipulate encryted data as part of a system configuration?
<jpt4>E.g., could the (password) field reference a file like .shadow?
<jpt4>I am further curious whether anyone has successfully experimented with disk encryption on GSD, since the installer now comes with dm-crypt.
<jpt4>Greetings, #guix guix (few organizations can claim to be so demonymous).
<sir123>Hey, i have burned a USB ISO and have booted into the live, but dhclient reports unknown interface: No such device! What can I do?
<DusXMT>sir123: ifconfig -a
<DusXMT>We use eudev, it names network devices differently than classic udev
<sir123>Ok, there's quite a bit, sorry I'm using my Replicant phone
<DusXMT>Scrolls off screen? In that case, ifconfig -a | less
<civodul>sir123: the ethernet device is typically called "eno1" if you have a single Ethernet card in your machine
<civodul>i think the manual erroneously mentions "eth0" somewhere
*civodul fixes that
<DusXMT>it does
<civodul>yeah, i noticed it a while back but forgot to fix
<sir123>No, but I'm not particularly fast, sorry. Three parts: a link encap:ethernet, a link encap:local loopback and a wlp3s0 link encap:ethernet. I'm using a wireless card that I know works under free software
<sir123>I'll try eno0
<DusXMT>sir123: I'd try wlp3s0
<sir123>Ok, link is not ready, waiting...
<sir123>Thank you for this distro too, it looks great!
<civodul>sir123: "eno1", i think
<sir123>And back to prompt, what should i do?
<sir123>Unknown host
<jpt4>Are you connected to a network?
<civodul>does "ping" work?
<sir123>No, my wireless card doesn't even seem to be initialized yet
<DusXMT>sir123: you might have to use wpa_supplicant, I don't know if it's on the installer system though
<sir123>I don't think the kernel knows about it, tbh
<jpt4>It is.
<jpt4>wpa_supplicant, that is.
<jpt4>What kind of wireless are you trying to access, sir123?
<civodul>sir123: many wifi cards require non-free firmware, which is not provided
<civodul>you need either an ath9k-based wifi card, or a good'ol ethernet card
<sir123>A local router, and it has worked under Parabola, Trisquel, etc.
<sir123>I've tried this on other GNU/Linux FSF approved systems before
<jpt4>You may try writing your own wpa_supplicant.conf.
<sir123>Ok. Any suggestions?
<civodul>sir123: i gave suggestions above :-)
<civodul>could you tell us what your wifi card is?
<sir123>Can't I lspci it? Sorry, I cant remember
<civodul>what does "iwconfig" report?
<sir123>The first two are empty, wlp3s0 reports mode:managed, access point not-associated, etc
<sir123>Essid is off/any
<jpt4>lspci | grep 'Network controller' will give your wi-fi card.
<jpt4>*should give
<civodul>sir123: so you need to configure wlp3s0 with 'iwconfig', 'iw', or 'wpa_supplicant'
<civodul>ATM it's up to the user to configure the network interface
<sir123>Ok, Network controller: Atheros Communications Inc. AR9285 Wireless Network Adapter
<civodul>let's say you have a wifi network called "mynet" without password, you can first run "ifconfig wlp3s0 up && iwconfig wlp3s0 essid mynet key off"
<civodul>and then run "dhclient -v wlp3s0"
<sir123>Perfect! Thank you guys so much! Its DHCPDISCOVERing
<sir123>Uh, it's saying 'Error for wireless request "Set Encode" (8B2A)
<sir123>Invalid argument <password>
<jpt4>Is the network password protected?
<sir123>Not literally, i did put the password in, yes
<jpt4>'iw dev wlp3s0 scan' will report the visible wi-fi networks.
<jpt4>For your desired net, what does the "Authentication Suites" field say?
<sir123>Its spitted out a bunch of data, i need to scroll up
<jpt4>| less is a terminal's best friend.
<sir123>Oh wait i can grep it im an idiot
<sir123>Ok, auth suites is psk
<jpt4>Very good. Have you written a custom wpa_supplicant.conf file before?
<sir123>No, but I'm ready to learn
<jpt4>Unfortunately, the GSD install doesn't have the man page for wpa_supplicant.conf.
<jpt4>So here is the file, line by line:
<jpt4>'zile /etc/wpa.conf'
<jpt4>(with quotes)
<jpt4>(with quotes)
<jpt4>c-x-s to save
<ewemoa>answering my own question: helps to have the right path when specifying -L
<jpt4>*cntr-x-s to save
<jpt4>*crtl-x-c to exit
<sir123>Emmacs clone for certain
<jpt4>'wpa_supplicant -B -Dnl80211,wext -iwlp3s0 -c/etc/wpa.conf'
<jpt4>B to run as background
<civodul>ewemoa: assuming test.scm is in the current directory, you should be able to run "guix build -L . foo", where "foo" is a package defined in ./test.scm
<jpt4>D to load drivers
<jpt4>i for interface, c for conf file
*jpt4 crosses fingers
<sir123>Its throwing back its usage reference
<sir123>I wrote it correctly.
<jpt4>Aside from the -D, it should be similar to the example at the bottom of the help output.
<sir123>Should i clear the wext?
<jpt4>Yes, try that.
<sir123>No, same issue.
<jpt4>Try only wext.
<sir123>What do you mean?
<jpt4>The generic linux wireless driver.
<sir123>How should I try that? I don't think linux picked it up
<sir123>I cant see what im doing wrong
<sir123>Ill write it back
<ewemoa>civodul: thanks, unfortunately with . (this was inside a guix/gnu/packages dir) i kept getting 'unknown package', somehow specifying the guix/ ancestor dir as the path seems to work better...
<sir123>wpa_supplicant -Dwext -wlp3s0 -c/etc/wpa.conf
<sir123>Exactly like that
<jpt4>sir123, you need the flag '_B', and '-iwlp3s0'.
<jpt4>-i for the interface
<sir123>Oh, sorry
<jpt4>The lack of spaces is more difficult to parse.
<sir123>And it has rejected every line of the config.
<sir123>Was it all meant to be on one line? Sorry
<jpt4>I don't know if it matters, but it was intended to be newline delimited.
<jpt4>Instead of "Network"
<sir123>It works.
<sir123>Link is ready! Thank you guys so much!
<sir123>Dhclient works!
<sir123>Ping google works.
<sir123>Thank you SO much!
<jpt4>You are welcome. I am new to GSD as well, glad to see another convert.
<sir123>Congratulations on being FSF certified, btw.
<davexunit>happy to see new folks around here :)
<sir123>I'd better finish this.
<jpt4>The template config in the docs
<jpt4>is suboptimal in my experience.
<jpt4>There are a few better examples on the internet
<sir123>Make it a todo? :)
<jpt4>Here are the links:
<sir123>I'll be sure to use it, thanks.
<jpt4>If any more experienced users have better recommendations, I would greatly appreciate them.
<jpt4>Good luck sir123, may your next irc visitation be from a GSD machine.
<sir123>Goodbye, thank you! I am in your debt!
<davexunit>jpt4: what's suboptimal about the example config?
<jpt4>It is quite spartan, to the point of not demonstrating useful config syntax.
<davexunit>such as?
<jpt4>One moment please.
<davexunit>I think we could change the example to be more helpful, provided that it remains simple.
<davexunit>just curious about what you'd like to see explained.
<jpt4>Without the examples I linked
<jpt4>I wouldn't have known how to more fully configure a user account.
<jpt4>This may be a deficit in my reading of the documentation.
<davexunit>jpt4: the user account API is described in section 6.5.2
<davexunit>err, 6.2.5
<jpt4>Also, not having a (packages) field discomfitted me until I saw the above examples.
<jpt4>Thank you for the reference.
<jpt4>6.2.1 has a better example.
<ewemoa>here's an attempt for fluxbox:
<jpt4>(Which I now recall reading at some point.)
<davexunit>ewemoa: cool! does it build? :)
<jpt4>"'Fluxbox is a X window amanger'"
<jpt4>Thank you, ewemoa, this is a fine benchmark for my own packaging efforts.
<davexunit>jpt4: there's lots of good examples in gnu/packages/
<bavier`> has an expired certificate
<ewemoa>davexunit: guix build seemed to produce something and guix package -i seemed to put something in my path
<jpt4>davexunit: Thank you. When is it appropriate/necessary to write a package module vs. a package?
<ewemoa>yes, it does seem to have an expired cert
<davexunit>ewemoa: that's a good sign. now try using it and see if it actually works.
<ewemoa>jpt4: thanks for the correction
<ewemoa>davexunit: windowmaker seemed to block my efforts and it's time for sleep :)
<davexunit>jpt4: we use modules to group related packages to the best of our ability. you should try to fit your package into an existing module, if one of them makes sense.
<jpt4>Very well. It seems like certain packages are their own modules, however. Lynx, for instance, was an undefined variable until included within (use-package-modules).
<davexunit>jpt4: yes, some modules contain only a single package.
<bavier`>a loose convention is to put GNU packages in their own module
<jpt4>Are packages are strictly contained within package modules?
<davexunit>our convention is that they live in the (gnu packages ...) namespace.
<jpt4>Such that a package can not be specified under (packages) if its module is not in (use-package-modules)?
<davexunit>yes, you must import the module that contains the relevant package variables.
<davexunit>use-package-modules is just sugar for importing modules from the (gnu packages *) namespace
<jpt4>I see, thank you.
<davexunit>the module system is how we compartmentalize code in Guile.
<davexunit>in Guix, packages are just scheme objects, and the ones you are referencing in (packages ...) have been assigned to scheme variables that you've imported.
<jpt4>I will re-read 6.2 of the guide, now that I have an underlying GSD system to reference.
<jpt4>Again, I do hope to contribute to GSD/guix, and thank you and the rest of the developers for building this project.
<bavier`>jpt4: Thank you for your interest. :)
<sir123>Guys its me again
<sir123>Im having trouble with the os config
<sir123>It keeps saying end of file in string constant
<davexunit>sir123: you have a syntax error
<mark_weaver>jpt4: regarding passwords in the OS config, actually it's the crypted passwords that go there, the same as you'd see in /etc/shadow
<jpt4>sir123, that indicates an excess of parens terminating an expression before its time.
<mark_weaver>probably the doc could be better on this.
<davexunit>yeah, got confused about that before, too.
<jpt4>mark_weaver: Is there a guix utility to create encrypted passwords akin to passwd, or will they live in both shadow and config.scm?
<mark_weaver>civodul: are you sure that 'eno1' is typically the name of the ethernet device? on my Libreboot X60 it's enp1s0
<mark_weaver>jpt4: I don't think we currently have that, sorry. lots to do. you can just copy it out of an /etc/shadow file you already have, I guess.
<mark_weaver>but maybe there's a better way that I don't know about.
<mark_weaver>you can also just leave the password field out and run 'passwd' after first installation.
<mark_weaver>updating the system later (the common case) doesn't overwrite existing users. it just adds any that are missing.
<davexunit>does NixOS do the same? I question that behavior.
<civodul>mark_weaver: according to "eno1" is for on-board devices, while "enp1s0" means it's a PCI board
<jpt4>mark_weaver: Certainly, though if a more unified approach exists, it would be preferable.
<davexunit>I worry about the statefulness of stuff like that.
<civodul>davexunit: the problem is that user accounts are inherently stateful
<fchmmr><mark_weaver> civodul: are you sure that 'eno1' is typically the name of the ethernet device? on my Libreboot X60 it's enp1s0
<fchmmr>mark_weaver, civodul does guix use systemd?
<civodul>there's a lot of state associated with user accounts, such as home directories
<civodul>fchmmr: no; it uses GNU dmd
<mark_weaver>jpt4: there's almost certainly some utility somewhere that does that job.
<davexunit>civodul: well the home dirs don't have to go, but do they remain in /etc/passwd?
<fchmmr>mark_weaver, ok, so dmd has similar NIC device naming schemes to systemd?
<civodul>davexunit: currently yes; maybe we could change that, dunno
<mark_weaver>davexunit: if you really want to avoid all statefulness, you can run 'guix system init' on a fresh partition instead of 'guix system reconfigure'
<mark_weaver>(maybe appropriate for some applications)
<civodul>you can buy a new machine also ;-)
<davexunit>I accept some amount of statefullness.
<mark_weaver>hehe :)
<davexunit>I want my database to not be wiped when I reconfigure.
<davexunit>but then again, I don't specify the creation of my database in my OS config file
<davexunit>I *do* specify what users should exist.
<civodul>so really, what to do with user accounts is an open question i think
<civodul>maybe removing them would be nice, indeed
<mark_weaver>fchmmr: it's not dmd. it's eudev that names the devices. eudev is gentoo's fork of udev, since udev is now part of systemd.
<fchmmr>wow, I didn't know gnutoo did that. he's involved in a lot of free software projects it seems, all low level
<fchmmr>udev, replicant, coreboot
<mark_weaver>I'm pretty sure that we could configure user-specified aliases for those devices.
<mark_weaver>udev configuration files provide a lot of flexibility
<jpt4>civodul: User attributes may be mutable, but they are also portable. If a particular mutation is deemed canonical, e.g. by specification in a system wide config file, transplanting the config to a different machine should reproduce exactly the state at the time of specification.
<civodul>jpt4: that's what happens: 'usermod' is run to ensure that the configured account attributes are effective
<civodul>what does not happen is removal of no-longer specified accounts
<civodul>this is what davexunit was referring to
<davexunit>I worry about cruft accruing on machines, as seen with puppet and co.
<jpt4>Concerning unspecified accounts, where is root? Is there a %base-users?
<davexunit>if I as the sysadmin must take care to remove the users manually, I hit scaling problems when I try to revoke a user's access from 100 servers.
<davexunit>ideally, I'd like that to be a new generation of my GuixSD system.
<davexunit>guix can't help with deleting home dirs in any sane way, but it could ensure that the user is no longer valid.
<mark_weaver>jpt4: there's no %base-users. There's %root-account defined in gnu/system.scm and automatically added to the list of accounts provided by the user in 'operating-system-accounts', defined in the same file.
<mark_weaver>I'm not sure it's ideal, but it's what we have now.
<civodul>davexunit: i see, you're probably right
<mark_weaver>jpt4: oh, it's only added if you didn't add a root account yourself.
<mark_weaver>so actually, I think that's not bad. what do you think?
<civodul>davexunit: would you like to file it on bug-guix? :-)
<davexunit>civodul: sure! :)
<mark_weaver>davexunit: good points
<civodul>i'm not sure if there's an API to enumerate all the user accounuts
<davexunit>civodul: trying to think ahead towards "GuixOps" :P
<davexunit>because my plans are to manage large groups of machines with Guix. :)
<mark_weaver>we might want to provide a mode that inhibits deletion of users/groups though
<mark_weaver>(for casual home users)
<civodul>davexunit: in an NPO? ;-)
<davexunit>in my head, I have a marketting line: "from development to production, with Guix!"
<davexunit>'guix environment' is the first step for the development part
<mark_weaver>davexunit: btw, if we do as you suggest, then I think we should take steps to *prevent* users from modifying /etc/{passwd,group,shadow,gshadow} in any other obvious way.
<mark_weaver>because otherwise, people will run 'passwd' or add a user/group outside of guix, and be annoyed when guix undoes their work.
<davexunit>mark_weaver: is being owned by root not enough?
<davexunit>those files currently live outside of /gnu/store, yes? if we do what I propose, could they be immutable files in the store?
<mark_weaver>davexunit: well, they are normally owned by root, and users are accustomed to having to be root to modify them.
<civodul>mark_weaver: but we want to allow people to use 'passwd'
<davexunit>yes, true.
<mark_weaver>yeah, I don't know how to implement what I'm suggesting.
<mark_weaver>but it seems like people are likely to make that mistake and then scream at us when we undo their changes.
<davexunit>if they use passwd, guix would indeed undo their work, but that is true for other things in the system.
<davexunit>people experience this with puppet and co. already
<mark_weaver>I would actually go so far as to say that our current behavior should be the default.
<mark_weaver>and then to provide a mode that does the other thing
<davexunit>ideally, I'd like /etc/passwd to be another immutable thing.
<davexunit>I worry about the complexity of introducing 2 modes of operation for this, but perhaps it's the only way to satisfy everyone.
<mark_weaver>davexunit: I agree that's preferable, I just want to prevent bad surprises and people screaming at us :)
<mark_weaver>(which I think I might do if such a thing caught me by surprise)
<davexunit>yes, I agree.
<mark_weaver>the mode could be specified in the OS config.
<davexunit>I don't like the idea of having undocumented users in the system. it guides people to creating unreproducable systems.
<davexunit>is there a way to have /etc/passwd be immutable only *and* not surprise people? perhaps not.
<mark_weaver>davexunit: there's a lot of other mutable state in /etc currently
<mark_weaver>davexunit: for the ideal mostly-immutable system, but where you want a few things mutable like databases, it might be best to recreate your root partition from scratch everytime with 'guix system init', and then keep your explicitly mutable data on another partition.
<mark_weaver>the mutable data could be put into the system with either symlinks or bind mounts to the mutable partition.
<mark_weaver>(we support bind mounts in our OS config)
<davexunit>to me, there's a distinction with something like a database. the creation of a database wouldn't be something you specified in your OS config.
<davexunit>that's the kind of stateful stuff that guix need not bother with.
<jpt4>Unless legacy unix is to be abandoned entirely in favor of GuixOS (as opposed to GS*Distribution*), the aesthetic is one of guix as a safe, immutable overlay manipulating or replicating the function of imperative primitives.
<jpt4>Thus, the more functionality that is co-opted into the immutable sphere of control the better, as it disincentives system adminstration outside of it.
<mark_weaver>I think different users will want different sets of things managed immutably. for example, most casual users probably want their network manager to remember wireless networks they've connected to.
<davexunit>yes, agreed.
<mark_weaver>whereas for some other applications, you might want the wireless config to be entirely in the OS config file, and overwritten completely on every reconfigure.
<mark_weaver>jpt4: well said
<jpt4>mark_weaver: Why is a record of observed networks not immutable? As a time series, its monotonic. Also, is not "overwritten completely" a slight exaggeration given that previous configs can be resumed?
<jpt4>resumed -> selected at boot?
<davexunit>that specific example seems like like something that is saved in a user's home dir.
<davexunit>which of course, guix should not touch.
<mark_weaver>davexunit: mmm, it probably should be, but wicd doesn't work that way.
<mark_weaver>(we should deprecate wicd btw, since it's no longer maintained)
<jgrant>mark_weaver: Oh it isn't? It'd probably be realtively trivial to roll a interface for Wpa_supplicant and iw, really.
<mark_weaver>jpt4: well, some people might want to declare the list of wireless networks to auto-connect to (and their authentication info) in the OS config, such that they could remove an item from that list and the next 'guix system reconfigure' would completely overwrite the wireless config, removing anything that had been added by convenient GUI wireless config tools.
<davexunit>my rule of thumb seems to be: if it can be specificed in an OS config, it ought to be stateless. everything outside of that is stateful and guix will respect that.
<mark_weaver>jpt4: but many users want to be able to use a network manager GUI to join a network without having to reconfigure their system.
<mark_weaver>and then have that not be forgotten..
<davexunit>it's a shame that something like that would be a whole system setting, rather than a per-user one.
<mark_weaver>jgrant: yes, it would be fairly trivial
<mark_weaver>davexunit: well, network settings are system-wide. consider multi-user systems.
<mark_weaver>if two people are logged in at the same time, and network configuration is per-user, how do you handle that?
<davexunit>yeah, makes sense.
<jpt4>mark_weaver: I see, though I wonder if guix has the concept of "live reconfiguration"? If kexec can swap kernels out from under the user, why would a guix-integrated wifi-menu not be modelled as the input to a new, transparent system reconfig?
<mark_weaver>two people can be logged in to the console as well. sometimes two people share a computer, and some desktop environments support quick switching between them.
<mark_weaver>(where there are actually two X server running simultanously)
<jpt4>*as providing the input
<mark_weaver>jpt4: 'guix system reconfigure' is live in the sense that /run/current-system is immediately swapped out (but not /run/booted-system)
<mark_weaver>and normally, on a GuixSD system, /run/current-system/profile/bin is in PATH, ditto for many other environment variables.
<civodul>eventually 'guix system reconfigure' will also (re)start services when doing that doesn't have any undesirable side effects
<mark_weaver>jpt4: but I think that kexec can't do what you suggest
<civodul>kgraft can
<mark_weaver>I guess we support live patching of little bugs
<mark_weaver>but in the general case, you can switch to some other arbitrary kernel and migrate the data structures in a sane way.
<mark_weaver>well, I'd be *extremely* surprised if anyone had gotten that to work for anything other than small patches.
<davexunit>glibc 2.21 has been released.
<jpt4>mark_weaver: For the specific case of a guix-wicd then, could not selecting a new network generate a new specification of the running system, to be reported as a previous revision at boot?
<mark_weaver>it would require the kernel code to either cope with existing data structures from a different kernel, or the infrastructure to somehow convert those data structures on the fly.
<davexunit>jpt4: sounds overly-complex.
<mark_weaver>jpt4: you mean have it automatically edit your OS config file?
<mark_weaver>(and then it would have to run 'guix system reconfigure' automatically, or something)
<davexunit>that would be insane.
<jpt4>mark_weaver: Rather, produce a new config.scm.
<mark_weaver>jpt4: it amounts to editing it, because the new config.scm better be almost the same as I had it.
<davexunit>jpt4: it couldn't do that reliably. it could create a new operating-system object, but it could never preserve the code as you wrote it.
<mark_weaver>and then there's the question of what if you're not currently running the latest generation of your system.
<davexunit>this isn't a 2 way street. a human writes the config and tells guix to apply it.
<mark_weaver>what if you're currently booted into an older generation, which does not correspond to your OS config file.
<mark_weaver>davexunit +1
<jpt4>mark_wevaer: Currently, if I boot to an older system, do I not have an older /etc/config.scm?
<mark_weaver>I would prefer a model where the user can choose to make wireless configuration a part of the mutable world, or to make it part of their OS config, but not both.
<davexunit>jpt4: no, you do not.
<jpt4>Ah, so the system lineage is a chain, not a tree.
<davexunit>you're booting an older system that corresponds to an operating-system object that was read from a previous version of your config.scm file.
<mark_weaver>I could imagine implementing something analogous to emacs configure, which allows editing of a well-delineated part of .emacs
<jpt4>davexunit: The object corresponds deterministically to an older config though, correct?
<mark_weaver>but we'd better not do that without it being very obvious to the user what's happening, as in emacs.
<mark_weaver>I don't want the network manager GUI to magically edit my config behind the scenes :)
<davexunit>yeah, no way.
<mark_weaver>jpt4: the operating system object aims to be a pure function of the configuration file and the version of guix (e.g. git commit)
<jpt4>mark_weaver: Indeed, absent a revision controlled tree of (config, OS) pairs, I rescind my previous remarks concerning the immutable potential of network connections.
<mark_weaver>it's affected by any local changes you've made to your guix source tree, if you run guix out of the source tree (as I do)
<davexunit>jpt4: I highly recommend keeping your configs in version control, but the state of your text files is not the concern of guix ;)
<davexunit>I have 2 extra repos, one for configs, and one for extra packages. could probably roll it into one.
<jpt4>davexunit: Urbit and guix/gsd are my two favorite systems programming projects, the first of which influenced my former comments. However, I recognize the difference in scope and application between the two, and thank you and mark_weaver for clarifying.
<mark_weaver>jpt4: glad to have you here, your comments have been quite welcome
<davexunit>jpt4: you're welcome!
<jpt4>I read it, ijp.
<jgrant>Since we have more than one graphical session now, should we move away from slim-service or whatever adds windowsmaker?
<Sleep_Walker>I was always wondering - what sort of pattern does `guix package -d' accept?
<Sleep_Walker>I tried regexp, I tried shell pattern matching - none of it worked
<bavier`>Sleep_Walker: check the manual
<mark_weaver>section 3.2 (Invoking 'guix package')
<Sleep_Walker>bavier`: thanks
<Sleep_Walker>found it
<Sleep_Walker>I guess I needed to ask anyway
<Sleep_Walker>couldn't find it before :)
<mark_weaver>jxself: 3.18.6 is out!
<Sleep_Walker>jgrant: slim is "Simple LogIn Manager", it is able to select window manager by your choice
<jgrant>Sleep_Walker: I'm not sure what pulls it, but something pulls Windowsmaker in a simple install.
<jpt4>jgrant:%windowmaker and %ratpoison are Scheme variables associated with slim-service, according to
<mark_weaver>jgrant: see %default-sessions in gnu/services/
<mark_weaver>gotta run....
<jgrant>mark_weaver: Thanks for the pointer.
*jgrant investigates a bit and sees why it's seemingly being called.
<jgrant>being called, regardless.
<mark_weaver>jgrant: you can override the set of services supported by slim-service by adding the #:sessions keyword argument.
<mark_weaver>(in your OS config)
*mark_weaver goes afk again for a while
<jgrant>mark_weaver: Will it still download windowmaker though?
<davexunit>not if it isn't reference
<davexunit>in the g-expression
<jxself>mark_weaver: Yes.
<jxself>mark_weaver: But not the corresponding -libre version.
<jxself>And lxo has taken off to give a talk at a conference so there may be a delay.
<mark_weaver>jgrant: looks like you'll also need to pass #:auto-login-session to slim-service, because its default value refers to windowmaker.
<Sleep_Walker>oh, openvpn is still not packaged